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Vorwort 


Dieser Bericht beruht auf den Ergebnissen des Forschungsprojekts »Lean im 
Büro - Neue Industrialisierungskonzepte für die Kopfarbeit und ihre Folgen 
für Arbeit und Beschäftigte«. Es wurde zwischen 2013 und 2016 von der Hans- 
Böckler-Stiftung gefördert und von uns am Institut für Sozialwissenschaftliche 
Forschung - ISF München e.V. durchgeführt. 

Das Projekt reiht sich ein in eine langjährige Forschungspraxis, in der wir die 
Veränderungen in der Arbeitsorganisation und die digitale Transformation der 
Angestelltenbereiche empirisch untersucht haben. Ein wichtiges Forschungs- 
projekt in diesem Kontext war das ebenfalls von der Hans-Böckler-Stiftung 
geförderte Forschungsprojekt »Offshoring und eine neue Phase der Internatio- 
nalisierung von Arbeit - Konsequenzen für Arbeitsbeziehungen und Mitbe- 
stimmung« (Boes/Kämpf 2011), das die Veränderungen der Angestelltenarbeit 
im Kontext der Globalisierung zum Gegenstand hatte. Mit Blick auf den digita- 
len Umbruch bilden empirische Forschungsarbeiten in den laufenden Projekten 
»digit-DL - Digitale Dienstleistung in modernen Wertschöpfungssystemen. 
Neue Produktivitätspotenziale nachhaltig gestalten« (Förderung: Bundesmi- 
nisterium für Bildung und Forschung) und »WING - Wissensarbeit im Unter- 
nehmen der Zukunft nachhaltig gestalten. Beteiligungsorientierte Konzepte für 
die Arbeitswelt von morgen« (Förderung: Bundesministerium für Arbeit und 
Soziales) eine wichtige Grundlage unserer Ergebnisse und Überlegungen (vgl. 
z.B. Boes et al. 2016a, b, c). 

Unser Dank gilt zuallererst unseren Interviewpartnern in den Unterneh- 
men sowie den zahlreichen Experten, die uns mit großer Offenheit und in oft 
sehr ausführlichen Gesprächen praktische Einblicke in die Veränderungen der 
Arbeitsorganisation im Büro und die Folgen für die Beschäftigten im Kontext der 
Digitalisierung gegeben haben. Einen speziellen Dank schulden wir den Unter- 
nehmensvertretern, Gewerkschaftsvertretern und Betriebsräten, die den Kon- 
takt zu unseren Interviewpartnern vermittelt und diese Studie so erst möglich 
gemacht haben. Besonders bedanken möchten wir uns bei der Hans-Böckler- 
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Stiftung. Sie hat durch ihre finanzielle Förderung die materielle Grundlage für 
unser Forschungsvorhaben gelegt. Insbesondere Marc Schietinger haben wir hier 
für seine Unterstützung bei der Konzeption und für die kompetente Begleitung 
des Projekts zu danken. 

Die vielen Kolleginnen und Kollegen, am ISF München und anderswo, die 
unsere Arbeit in fruchtbarem Austausch begleitet haben, können hier nicht alle 
genannt werden. Hervorheben wollen wir zum einen die Mitglieder des Projekt- 
beirats, die das Projekt mit großem Engagement und mit vielen instruktiven 
Anregungen begleitet haben, und zum anderen Katrin Gül, Kira Marrs, Elisabeth 
Vogl und Alexander Ziegler, die uns im ISF München immer wieder wertvollen 
Input gegeben haben. 

Und schließlich danken wir: Setareh Radmanesch, die als Studentin einen 
wichtigen Beitrag zum Projekt und zu diesem Bericht geleistet hat, Karla Kemp- 
gens, die dem Projekt ein grafisches Gesicht gegeben hat, sowie Rainer Bohn und 
Frank Seiß für ihr kompetentes Lektorat und die konstruktiven Hinweise. 


München, im August 2017 
Andreas Boes, Tobias Kämpf, Barbara Langes, Thomas Lühr 
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1 Einführung 


Die Arbeitswelt erlebt derzeit rasante Veränderungen und Umwälzungen. Ange- 
trieben von der digitalen Transformation wird Arbeit heute neu gedacht. Viele 
vermeintliche Gewissheiten über die Organisation und Gestaltung von Arbeit 
werden heute in der Praxis auf den Prüfstand gestellt. Davon betroffen ist nicht 
nur die Fertigung, sondern vor allem der wachsende Bereich von Arbeit, die im 
Büro und »vor dem Computer« stattfindet. Gerade in der Welt der Angestell- 
ten - von der Verwaltung bis hin zur Forschung & Entwicklung - zeichnen 
sich tiefgreifende Umbrüche ab. Mit der Übertragung von Industrialisierungs- 
konzepten wie Lean gewinnt hier die Diskussion um die Industrialisierung von 
Wissensarbeit eine neue Brisanz. 


1.1 Digitale Transformation: 
Unternehmen auf der Suche nach einem neuen Bauplan 


Die digitale Transformation markiert einen grundlegenden Umbruch für die 
Arbeitswelt und unsere Gesellschaft insgesamt - historisch vergleichbar mit der 
industriellen Revolution im 19. Jahrhundert. Nachdem die Bedeutung der Digi- 
talisierung in Deutschland lange unterschätzt worden war, hat sie nun auch die 
deutsche Wirtschaft mit großer Dynamik erfasst: Es gibt kaum eine Branche, in 
der man sich nicht intensiv damit beschäftigt, wie Digitalisierung bestehende 
Geschäfts- und Produktionsmodelle verändert, wie Produkte und Dienstleistun- 
gen innoviert werden müssen und wie die Art und Weise des Arbeitens neu 
gedacht werden kann. 

Die Breite und Qualität der Veränderungen darf dabei nicht unterschätzt wer- 
den. Die deutsche Diskussion, die unter dem Label »Industrie 4.0« geführt wird, 
bildet lediglich den Anfang (vgl. die Beiträge in Hirsch-Kreinsen et al. 2015) und 
beschreibt mit ihrem Fokus auf Automatisierung nur einen kleinen Ausschnitt 
der digitalen Transformation. Entscheidend ist vielmehr, dass mit dem Aufstieg 
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des digitalen »Informationsraums« (Baukrowitz/Boes 1996) zu einer neuen ge- 
sellschaftlichen Handlungsebene eine neue Basisinfrastruktur für Arbeit ent- 
standen ist. Eine rasant wachsende Anzahl von Tätigkeiten und Arbeitsprozes- 
sen findet bereits heute in diesem neuen »Raum der Produktion« (Boes 2004) 
statt. Arbeitsmittel und -gegenstand stehen vielfach in digitaler Form zur Verfü- 
gung, und auch die Zusammenarbeit der Beschäftigten findet in diesem Raum 
statt. Betroffen ist nicht eine kleine Anzahl von »Nerds« oder »IT-Spezialisten«, 
sondern eine große und noch wachsende Mehrheit der Beschäftigten - von einer 
zunehmend digitalisierten Fertigung über die Wissensarbeit bis hin zu perso- 
nenbezogenen Dienstleistungen (z.B. im Gesundheitssektor). Schon heute deu- 
tet sich so ein regelrechter Produktivkraftsprung an: Was die Maschinensysteme 
der »großen Industrie« (Marx) für die Entwicklung von Arbeit im 19. und 20. 
Jahrhundert waren, scheinen die digitale Transformation und der Informations- 
raum im 21. Jahrhundert zu werden. 

Die damit verbundenen Umbrüche gehen weit über die bloße Automatisie- 
rung, den Verlust von Arbeitsplätzen und die Ersetzung einzelner Tätigkeiten 
durch »Algorithmen« und »Computer« hinaus (vgl. dazu etwa Frey/Osborne 
2013; Brynjolfsson/McAfee 2011). Vielmehr wird dieser Produktivkraftsprung 
zum Motor und Fundament der Reorganisation von Arbeit allgemein und betrifft 
insgesamt die Art und Weise, wie Unternehmen Wertschöpfung organisieren. Es 
geht z.B. darum, wie Arbeit in vernetzten Wertschöpfungssystemen organisiert 
wird, wie Innovationsprozesse funktionieren, wie Beschäftigte zusammenarbei- 
ten und ihr Wissen teilen und wie Unternehmen als Ganzes integriert und ge- 
steuert werden können (anschauliche Beispiele finden sich etwa in BMAS 2015). 
Über den digitalen »flow of information« können ganze Wertschöpfungsketten 
restrukturiert werden. Überall in den Unternehmen werden heute in der Folge 
strategische Pilotprojekte gestartet, die nach neuen Antworten suchen und die 
Organisation in Richtung einer digitalen Arbeitswelt entwickeln sollen. Dabei 
geht es nicht mehr um punktuelle Initiativen, sondern um eine grundlegende 
Neueinstellung der Unternehmen vor dem Hintergrund der digitalen Transfor- 
mation von Arbeit und Wirtschaft. 

Auf dem Prüfstand steht damit nichts Geringeres als das Konzept des fordis- 
tisch-bürokratischen Industrieunternehmens, das als Leitkonzept die Entwick- 
lung der Wirtschaft seit mehr als 100 Jahren geprägt hat. Seine Organisations- 
prinzipien - wie hierarchische Entscheidungsprozesse, starre Abteilungsgrenzen 
und organisatorische »Silos«, Führung nach dem Prinzip »Fürst im Reich« oder 
auch die strikte Trennung von Hand- und Kopfarbeit - stoßen in einer vernetz- 
ten Arbeitswelt immer mehr an Grenzen. Lange Planungszeiten, starre bürokra- 
tische Abläufe und Entscheidungsprozesse und mehrjährige Innovations- und 
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Entwicklungszyklen kann sich angesichts der rasanten Veränderungsdynamik 
der Märkte und Technologien kaum ein Unternehmen mehr leisten. Zur neuen 
Leitvorstellung entwickelt sich demgegenüber die Idee des »agilen Unterneh- 
mens«, in dem alles miteinander vernetzt ist, das hochgradig flexibel, aber doch 
»wie aus einem Guss« funktioniert, in dem Wertschöpfungsketten global und 
über die Grenzen der Organisation hinweg »systemisch integriert« werden und 
in dem Beschäftigte »empowert« werden und mit hoher Eigenverantwortung 
handeln (vgl. Boes et al. 2016a). Die Basis hierfür bildet der digitale Informa- 
tionsraum. Er wird zum Rückgrat der hochgradig vernetzten Organisations- 
strukturen, schafft eine völlig neue Qualität der Transparenz für die Steuerung 
und wird als »Raum der Produktion« zur Grundlage neuer Arbeitsformen. Auf 
dieser Grundlage sind die Unternehmen auf der Suche nach einem neuen Bau- 
plan für die Arbeitswelt von morgen. 


1.2 »Lean im Büro«: Von der digitalen Transformation 
zur Industrialisierung von Wissensarbeit? 


Eines der Zentren der Veränderungen und Umbrüche in den Unternehmen sind 
die Bürobereiche und damit das, was man Wissensarbeit nennt.' Diese auch als 
»indirekte Bereiche« gekennzeichneten Arbeitsfelder reichen von den mittelqua- 
lifizierten Bereichen der Verwaltung über die IT-Abteilungen bis hin zur For- 
schung & Entwicklung. Gerade in diesen Feldern ist die Digitalisierung schon 
heute weit fortgeschritten. Arbeitsgegenstände sind hier in der Regel digitalisierte 
Informationen -z.B. in Form einer digitalen Personalakte oder Abrechnung, eines 
Software-Codes oder einer CAD-Konstruktion -, die in komplexen digitalisierten 
Arbeitsumgebungen bearbeitet werden. Arbeit ist hier ohne Informationssyste- 
me kaum mehr vorstellbar, vernetzte Laptops, Tablets und Smartphones werden 
zum wichtigsten Werkzeug in der Arbeit. Vor diesem Hintergrund entfalten hier 
die Umbrüche der digitalen Transformation eine besondere Dynamik. In den 
Büros werden heute weitreichende und sehr grundlegende Veränderungen ange- 
stoßen. Der Informationsraum wird hier zum unmittelbaren »Raum der Produk- 
tion«, Arbeitsprozesse werden reorganisiert und die Unternehmen entwickeln 
für diese Arbeitsfelder neue Produktionsmodelle. Gerade für die Welt der Büros 
stellt sich so die Frage, wohin sich die Arbeitswelt der Zukunft entwickeln wird. 


1 | Der Begriff der Wissensarbeit genügt streng wissenschaftlichen Kriterien kaum. Zu 
den Tücken dieses Begriffs, aber auch alternativer Begriffsstrategien siche Boes/Kämpf 
(2013). 
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Im Zeitalter des bürokratisch-fordistischen Unternehmens hatten diese Be- 
reiche lange eine Sonderstellung. Auf der einen Seite erschienen sie zahlenmäßig 
im Vergleich zu den riesigen Fertigungsbereichen der industrialisierten Massen- 
produktion geradezu als »Anhängsel« - wenngleich hier Planung, Kontrolle und 
Entscheidungsmacht gebündelt wurden. Zum anderen entzogen sie sich den 
traditionellen tayloristischen Rationalisierungsstrategien (vgl. dazu Berger/Offe 
1981; Littek/Heisig 1995). Neben der bürokratischen Verwaltung entwickelten 
sich so gerade in den hochqualifizierten Bereichen Arbeitsformen, die im Sinne 
einer »verantwortlichen Autonomie« (Friedman 1977) von hohen individuellen 
Freiheitsgraden geprägt waren. Mit der zunehmenden Informatisierung der 
Wertschöpfung (Boes/Kämpf 2012; vgl. auch Kapitel 2.2) hat die Zahl der hier 
Beschäftigten jedoch stetig zugenommen und übertrifft heute in vielen Fällen 
die Zahl der in den direkten Bereichen tätigen Werker weit. Selbst in vielen tra- 
ditionellen Industrieunternehmen arbeitet heute in der Regel bereits die Mehr- 
zahl der Beschäftigten in den indirekten Bereichen. 

Dazu haben in den letzten Jahren auch in diesen Feldern Prozessorientie- 
rung und Standardisierung vermehrt Einzug gehalten. Die Beispiele reichen 
hier vom Bereich der IT-Dienstleistungen und »Software-Factories« (vgl. z.B. 
Greenfield/Short 2006) über moderne Call-Center (z.B. Holman/Batt/Holtgre- 
we 2007; Matuschek et al. 2007) bis hin zur Restrukturierung der industriellen 
Forschung & Entwicklung (Will-Zocholl 2011; Streckeisen 2008). Insbesondere 
der Aufstieg von »Shared-Services-Konzepten« (Bergeron 2003) markierte hier 
eine neue Qualität. Auf Basis einheitlicher IT-Systeme werden nun die Arbeits- 
prozesse der klassischen Bereiche der Industrieverwaltung - von den Finanz- bis 
hin zu den Personalabteilungen - nahezu durchgängig standardisiert, ggf. auto- 
matisiert und nicht selten in Niedriglohnstandorte verlagert. In diesen Feldern 
werden heute auf Basis von Ticketsystemen und digitalen Arbeitsumgebungen 
Aufgaben - standardisiert und industriell getaktet - wie an einem »digitalen 
Fließband« prozessiert und abgearbeitet (ausführlich dazu Boes et al. 2016b). 

Gegenwärtig haben die Umwälzungen der indirekten Bereiche in vielen 
Unternehmen eine neue Wendung genommen: Die Unternehmen beginnen 
nun, die Ansätze der Lean Production (grundlegend dazu Womack/Jones/Roos 
1991) in neuer Qualität auf ihre Angestelltenbereiche zu übertragen. Ausgehend 
von der japanischen Automobilindustrie haben die Ideen von Vordenkern wie 
Taiichi Ohno (1993) die industrielle Fertigung weltweit revolutioniert und die 
Produktivität enorm gesteigert. Unter dem Label der »Ganzheitlichen Produk- 
tionssysteme« (GPS) fanden die Konzepte und Ideen auch in Deutschland breite 
Anwendung (vgl. aktuell dazu Abel/Ittermann/Steffen 2013; Kötter/Schwarz- 
Kocher/Zanker 2015). Der besondere Charakter der Lean-Konzepte besteht in 
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dem ganzheitlichen Blick auf den gesamten Wertschöpfungsprozess und dem 
möglichst effizienten, verschwendungsfreien Zusammenspiel der Teilprozesse. 
Nachdem unter dem Eindruck des tayloristischen Paradigmas der Fokus lange 
auf der bloßen Rationalisierung einzelner Tätigkeiten gelegen hatte, gewann 
mit der Lean Production wieder ein Industrialisierungskonzept an Bedeutung, 
das auf eine konsequente Prozessorientierung und eine »systemische Integra- 
tion« (Bultemeier/Boes 2013) der gesamten Wertschöpfungskette zielt. Gerade 
in der Fertigung bilden dann Fließfertigung, synchrone Taktung und Optimie- 
rung der Materialbereitstellung ®Kanban«-Systeme) die strategischen Säulen, 
um Arbeit im Marx’schen Sinne nach einem »objektiven Prozesses« zu organisie- 
ren. Auf dieser konzeptionellen Grundlage gewinnen dann auch die berühmten 
Werkzeuge wie Gruppenarbeit, Just-in-time, Kontinuierliche Verbesserung und 
Kaizen sowie die Vermeidung von Verschwendung (muda) ihre grundlegende 
Bedeutung. 

Schon in der Vergangenheit wurde Lean auch in Bereichen wie Forschung & 
Entwicklung oder auch der Verwaltung angewendet (vgl. dazu bereits Womack/ 
Jones/Roos 1991). Die konkreten Auswirkungen blieben dabei jedoch über- 
schaubar und waren nicht vergleichbar mit den Umwälzungen in der Fertigung. 
Lean wurde hier mehr als »Management-Philosophie« verstanden und weniger 
als Konzept für die Etablierung neuer Produktionsmodelle in den indirekten 
Bereichen. Blickt man heute in die Praxis, scheint sich dies zu ändern. Lean wird 
heute auch im Büro und in den Angestelltenbereichen zum Ausgangspunkt für 
großflächige Reorganisationen und neue Arbeitsformen. Im Vordergrund ste- 
hen hier zwei strategische Entwicklungstrends: 


e Auf der einen Seite beginnen die Unternehmen, die Werkzeuge und Konzep- 
te ihrer Ganzheitlichen Produktionssysteme (GPS) konsequent auf die indi- 
rekten Bereiche auszudehnen. Betroffen sind sowohl die Verwaltung als auch 
hochqualifizierte Arbeitsbereiche wie Forschung & Entwicklung. Vorreiter 
sind insbesondere große Industriekonzerne, die bereits bei der Entwicklung 
der GPS eine führende Rolle eingenommen haben. Anders als in der Vergan- 
genheit scheinen nun bei der Übertragung auf die indirekten Bereiche groß 
angelegte Initiativen zur Reorganisation von Arbeit angestoßen zu werden. 
Dabei geht es nicht mehr nur um Einzelmaßnahmen, sondern der Arbeitspro- 
zess als Ganzes steht nun im Fokus. Nicht zuletzt die flächendeckende Einfüh- 
rung von Shopfloor-Management erweist sich als ein übergreifender Trend. 

e Auf der anderen Seite wird die IT-Industrie zu einem wichtigen Vorreiter neu- 
er Lean-Konzepte. Nachdem interessanterweise zunächst indische Unterneh- 
men aus dem Bereich der IT-Dienstleistungen Lean für die Optimierung ihrer 
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Prozesse nutzten (Upton/Fuller 2005; Upton/Staats 2006), ist heute das Feld 
der Software-Entwicklung in den Fokus gerückt. Als Gegenentwurf zu den 
bürokratischen, linear strukturierten und kaskadenförmig aufgebauten Pro- 
jekten der Vergangenheit ®Wasserfallprojekte«) wurde mit der Verknüpfung 
von Lean mit agilen Entwicklungsmethoden wie Scrum ein neues Produk- 
tions- bzw. Entwicklungsmodell geschaffen (Details dazu in Kapitel 2.1.2). 
Dieses Modell hat einen Paradigmenwechsel in der Software-Entwicklung 
eingeleitet und beginnt sich in der IT flächendeckend durchzusetzen. Auch 
in der industriellen Forschung & Entwicklung kommen diese neuen Arbeits- 
formen nun verstärkt zum Einsatz. 


Indem einerseits der digitale »Informationsraum« Möglichkeiten eröffnet, Arbeit 
neu zu denken und zu strukturieren, und indem andererseit Lean Anküpfungs- 
punkte für eine systemisch integrierte Reorganisation liefert, stellt sich auch die 
Frage nach der Industrialisierung von Wissensarbeit mit neuer Aktualität. Mit der 
digitalen Transformation gewinnt ein »neuer Typ der Industrialisierung« (Boes 
2004) an Kontur, der nicht mehr primär an den Maschinensystemen ansetzt, 
sondern seinen Ausgangspunkt auf der Informationsebene im Fluss digitaler In- 
formationen hat - und so auch die geistigen Tätigkeiten bzw. die Wissensarbeit 
neu erfasst. Die Durchsetzung und Gestaltung eines neuen Typs der Industria- 
lisierung ist dabei kein »technisches« Problem. Es geht vielmehr darum, wie in 
der sozialen Praxis die neue Produktivkraftstruktur in konkrete Produktions- 
modelle und neue Formen der Arbeitsorganisation übersetzt wird. Hier stellt 
sich die Frage, welche Rolle Industrialisierungskonzepte wie Lean in der Praxis 
spielen und welchen Beitrag sie hier leisten können. Empirisch gilt es zu unter- 
suchen, welche Gestalt die neuen Produktionsmodelle in der Praxis annehmen, 
wie Arbeit konkret organisiert wird und in welche strategische Richtung sich 
die Umwälzungen der Arbeitswelt in den Büros entwickeln. 


1.3 Was wird aus den Angestellten? 
Lean und die Folgen für Beschäftigte und Mitbestimmung 


Mit Verwaltung und Forschung & Entwicklung, aber auch den IT-Abteilungen 
stehen typische Angestelltenbereiche im Zentrum dieser Entwicklung. Damit 
sind Beschäftigtengruppen betroffen, die in der Vergangenheit - gemessen an 
den Bedingungen in der Fertigung - über besondere, »privilegierte« Arbeits- 
bedingungen verfügten. Diese spezifische Stellung war auch Ausdruck des Um- 
stands, dass sich diese Arbeitsbereiche den üblichen, zumeist tayloristischen 
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Rationalisierungs- und Kontrollstrategien entzogen. Hohe Freiheitsgrade in der 
Arbeit, verknüpft mit ausgeprägten »Primärmachtpotentialen« (Jürgens 1984), 
kennzeichneten in der Folge gerade die Arbeitssituation der hochqualifizierten 
Beschäftigtengruppen. Damit verbunden waren zumeist eine überdurchschnitt- 
liche Bezahlung sowie stabile und sichere Arbeitsverhältnisse, gewöhnlich auch 
verknüpft mit planbaren Karrierewegen. 

Schon mit der Krise des Fordismus hat dieses Szenario deutliche Risse be- 
kommen - auch die Welt der Angestellten wurde nun verstärkt zum Gegenstand 
von Restrukturierungs- und Konsolidierungsprogrammen (vgl. dazu z.B. be- 
reits Kadritzke 2003, 2004, 2005; Kotthoff 1997; Ahlers/Trautwein-Kalms 2002). 
Diese Initiativen waren mehr als nur einzelne und konjunkturell bedingte Ab- 
bauprogramme; sie markierten in vielen Unternehmen strategisch angelegte 
und sehr umfassende Reorganisationsmaßnahmen gerade in den Angestellten- 
bereichen (vgl. dazu z.B. Boes/Kämpf 2011, S. 229£.), die zu neuen Unsicherhei- 
ten in den Belegschaften führten. Besondere Bedeutung hatten in diesem Zu- 
sammenhang neue Formen der Globalisierung. Unter dem Label »Offshoring« 
(auch »Nearshoring«) wurde auch in hochqualifizierten Arbeitsbereichen, z.B. 
der Software-Entwicklung, begonnen, neue Standorte in Niedriglohnregionen 
aufzubauen (vgl. dazu Boes 2004, 2005; Sahay/Nicholson/Krishna 2003; Aspray/ 
Mayadas/Vardi 2006; Mayer-Ahuja 2011; Feuerstein 2011). Auch über hochquali- 
fizierten Beschäftigten hängt heute das »Damoklesschwert« einer Verlagerung 
ihrer Arbeitsplätze (ausführlich dazu Boes/Kämpf 2011; Kämpf 2008). 

Diese Entwicklungen haben die Arbeitsbedingungen erheblich verändert. 
Nicht mehr die »Beschaulichkeit« der »verantwortlichen Autonomie« bestimmt 
heute in weiten Bereichen der Angestelltenarbeit die Szenerie, sondern ein neues 
»System permanenter Bewährung« (Boes/Bultemeier 2008, 2010): Täglich gilt es 
mit überdurchschnittlichen Leistungen immer wieder neu zu zeigen, dass man 
es weiterhin »verdient« hat dazuzugehören. Viele Beschäftigte erleben diesen 
Wandel auch als eine tiefgreifende Ökonomisierung der Unternehmenskultur. 
Nicht nur als Menschen, sondern auch in ihrer Rolle als Experten und Fach- 
kräfte fühlen sie sich nicht mehr anerkannt und wertgeschätzt. Hier werden 
Verschiebungen der Anerkennungsordnungen und nicht selten ein Bruch der 
»impliziten Verträge« (Kotthoff 1997; Rousseau 1995; Raeder/Grote 2001) er- 
kennbar. Die tiefgreifenden Folgen dieser Veränderungen spiegeln sich auch in 
der erheblichen Zunahme psychischer Erkrankungen (Stichwort »Burn-out«) 
wider, die wir als Resultat einer neuen Belastungskonstellation in der Kopfarbeit 
interpretieren (vgl. Kämpf 2015; Kämpf/Boes/Trinks 2011; Gerlmaier/Latniak 
2011; Becke et al. 2010). 
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Vor dem Hintergrund dieser Veränderungen stellt sich nicht zuletzt die Fra- 
ge, wie sich die Umbrüche in den Angestelltenbereichen und der Einsatz neuer 
Lean-Konzepte auf die Arbeitsbedingungen auswirken und welche Folgen damit 
für die Beschäftigten verbunden sind. Nicht nur die Entwicklung der Angestell- 
tenbereiche in den letzten Jahren, sondern auch die Erfahrungen mit Lean in der 
Produktion lassen hier eine gewisse Skepsis ratsam erscheinen: Den positiven Er- 
wartungen, die gerade mit der Diskussion um die »neuen Produktionskonzepte« 
(Kern/Schumann 1984) verbunden waren, folgte in der Praxis in vielen Fällen 
bald eine Ernüchterung. Ein einseitiger Fokus auf Produktivitätssteigerungen 
und ein Mangel an Orientierung in Richtung Nachhaltigkeit und Innovation 
haben nicht selten dazu geführt, dass sich Arbeitsbedingungen kaum verbesser- 
ten oder dass sogar neue Belastungen entstanden (vgl. Gerst 2010, 2011). Offen 
ist, ob aus diesen Erfahrungen wirklich gelernt wurde oder ob diese Fehler auch 
bei einer »zweiten Welle« von Lean, nun in der Wissensarbeit, wiederholt wer- 
den. Hier deuten sich aktuell grundlegende Weichenstellungen an: Werden die 
neuen Konzepte in den Unternehmen vor allem dazu genutzt, die Produktivität 
zu steigern, eine höhere Austauschbarkeit von (hoch-Jqualifizierter Arbeitskraft 
zu erzielen und mit neuen Industrialisierungskonzepten die Kopfarbeit erst zu 
einer »echten« Lohnarbeit zu machen - oder geht es darum, im Sinne einer 
nachhaltigen Strategie innovative Formen der Arbeitsorganisation zu entwi- 
ckeln und so mit der digitalen Transformation neue Potenziale für die Nutzung 
geistiger Produktivkraft zu erschließen? 

Die Veränderungen in der Welt der Angestellten werfen bedeutsame Fragen 
hinsichtlich der Veränderungen der Arbeitsgesellschaft insgesamt auf. Sie betref- 
fen nicht nur die Gestalt von Arbeits- und Produktionsprozessen, sondern auch 
eine Verschiebung der im Fordismus gewachsenen gesellschaftlichen Klassen- 
und Konfliktstrukturen. Wenn neue Lean-Konzepte dazu genutzt werden, eine 
»Zeitenwende im Büro« (Boes/Kämpf 2010; vgl. dazu auch Boes/Trinks 2006) 
voranzutreiben, sind gerade in der vormals stabilen Mittelschicht, die sich in we- 
sentlichen Teilen aus Bereichen der Kopfarbeit rekrutiert, Abstiegs- und Ausdif- 
ferenzierungsprozesse zu erwarten (vgl. Boes/Kämpf/Lühr 2016c). Während die- 
jenigen Teile dieser Schicht, die ihre »Ungewissheitszonen« (Crozier/Friedberg 
1979) im Arbeitsprozess auch in der digitalen Arbeitswelt erhalten können, wei- 
ter privilegierte bzw. sich sogar verbessernde Arbeits- und Lebensbedingungen 
erwarten können, gilt dies kaum für diejenigen Beschäftigtengruppen, die sich 
mit einem »neuen Typ der Industrialisierung« und einem darauf aufbauenden 
»System permanenter Bewährung« konfrontiert sehen. Die Abstiegsängste brei- 
ter Teile der Mittelschicht bekämen damit eine neue Substanz: Prekarisierung 
und neue Unsicherheiten basieren nicht mehr allein auf Ausstrahlungseffekten 
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und veränderten sozialpolitischen Rahmenbedingungen (vgl. dazu z.B. Castel 
2000; Dörre 2005; Castel/Dörre 2009), sondern auf tiefgreifenden Veränderun- 
gen in der Sphäre der Arbeit selbst. 

Damit stehen auch Mitbestimmung und Betriebsräte vor neuen Heraus- 
forderungen. Mit Blick auf eine nachhaltige Gestaltung neuer Lean-Konzep- 
te besteht großer Handlungsbedarf (vgl. dazu z.B. Gerst 2010). Nicht zuletzt 
der deutliche Anstieg psychischer Belastungen in Bereichen hochqualifizierter 
Arbeit zeigt, dass die Gestaltung dieses Strukturwandels von Kopfarbeit zu 
einem zunehmend wichtigen Handlungsfeld für Betriebsräte wird. Mit den An- 
gestelltenbereichen wird dabei ein Feld adressiert, in dem Betriebsräte traditio- 
nell über geringere Einflussmöglichkeiten verfügen als etwa in der Produktion. 
Trotz dieser schwierigen Ausgangssituation müssen nun - auch auf Basis der 
Erfahrungen mit Lean in Produktionsbereichen - neue Antworten und Strate- 
gien gefunden werden, wie Lean in der Kopfarbeit in Richtung Nachhaltigkeit 
orientiert werden kann und so die Interessen der betroffenen Belegschaften zur 
Geltung gebracht werden können. 


1.4 Zum Aufbau der Studie 


Im folgenden Kapitel stecken wir zunächst in drei Schritten den Rahmen ab, 
in dem sich unsere Untersuchung bewegt: Erstens (Kapitel 2.1), indem wir das 
Konzept der Lean Production in jenen Grundzügen rekapitulieren, die für die 
Übertragung von Lean auf die Angestelltenbereiche von Bedeutung sind (Kapi- 
tel 2.1.1), und relevante Ziele, Methoden und Instrumente ansprechen, die für 
Lean-Konzepte und agile Methoden in der Arbeit der Angestellten sowie der 
industriellen und Software-Entwicklung charakteristisch sind (Kapitel 2.1.2). 
Dieser letztere Abschnitt soll auch dazu dienen, sich einen ersten Überblick 
über die für viele Leserinnen und Leser vielleicht ungewohnte Fachterminolo- 
gie der »Lean-Welt« zu verschaffen; eine Terminologie, die sich dann (jeweils 
durch kursive Schrift gekennzeichnet) durch die ganze Publikation zieht und 
an vielen Stellen noch weiter präzisiert werden wird. Im zweiten Schritt (Ka- 
pitel 2.2) kommen wir auf die theoretisch-konzeptuellen Grundlagen zu spre- 
chen, an denen wir uns orientieren; im dritten Schritt (Kapitel 2.3) schließlich 
auf unsere methodische Vorgehensweise und die empirische Basis, die unserer 
Untersuchung zugrunde liegt. 

Kapitel 3 enthält das empirische Herzstück der Studie: sechs Intensivfallstu- 
dien aus sechs Unternehmen, die jeweils mit einer kurzen Vorstellung der Unter- 
nehmen beginnen, dann die spezifische Geschichte der Einführung von Lean 
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und, soweit anwendbar, agilen Methoden beschreiben und sich schließlich der 
konkreten Arbeitspraxis der Beschäftigten und ihrer spezifischen Perspektive 
auf den Wandel ihrer Arbeitsorganisation und Arbeitsweise zuwenden. Jede 
Fallstudie wird von einem kurzen Fazit abgeschlossen. In Kapitel 4 führen wir 
unsere Forschungsergebnisse fallstudienübergreifend zusammen und nehmen 
schließlich in Kapitel 5 eine Gesamtbewertung in der Form eines Ausblicks vor. 
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2 Konzeptueller Rahmen, 
Methoden und empirische Basis 


2.1 Von der Lean Production zu Lean im Büro 


Im Zuge des gegenwärtigen Umbruchs in den Angestelltenbereichen haben 
Lean-Konzepte große strategische Bedeutung erlangt. Versuche, Industrialisie- 
rungskonzepte der Handarbeit auf die Kopfarbeit und die Angestelltenbereiche 
zu übertragen, hatte es bereits in der Phase des Fordismus gegeben. Dabei waren 
vor allem tayloristische Verfahren zum Einsatz gekommen (vgl. dazu grund- 
legend Braverman 1977). In der Praxis sind diese Ansätze zumeist gescheitert 
(z.B. Berger/Offe 1981; Hartmann 1981, 1984), vor allem dadurch, dass sie durch 
ein starres, bürokratisches Prozessverständnis notwendige Freiheitsgrade und 
Handlungsspielräume in der Arbeit einschränkten, die Rolle von Subjektleis- 
tungen im Arbeitsprozess unterschätzten und dadurch die Produktivität letzt- 
lich minderten. 

Mit der Orientierung an Lean-Konzepten wird in jüngerer Zeit versucht, die 
früheren Fehler zu vermeiden. Angestrebt wird, auch in der Verwaltung und 
den Entwicklungsabteilungen durch synchrone Arbeitsprozesse - auf Basis von 
Taktfluss, Pull-Prozessen sowie einer Null-Fehler-Orientierung und der Reduzie- 
rung von »Verschwendung« - die Produktivität zu steigern. Vor allem zahlreiche 
Industrie-Unternehmen beginnen nun in diesem Sinne, ihre Erfahrungen mit 
Lean aus der Fertigung in die Büros zu übertragen (vgl. z.B. Böhm 2015; Bür- 
kardt/Seibold 2015; Radmanesch 2016). In der Philosophie der Lean-Konzepte 
war dies konzeptionell immer schon angelegt (Womack/Jones/Roos 1991; Ohno 
1993; Womack/Jones 1997; Morgan/Liker 2006), doch blieb der flächendeckende 
Einsatz der neuen Organisationskonzepte in der Kopfarbeit praktisch weitge- 
hend aus. Zwar wurden einzelne Prinzipien, wie etwa der kontinuierliche Ver- 
besserungsprozess (KVP), auch in den indirekten Bereichen eingesetzt - aber 
eine ganzheitlich bzw. systemisch angelegte Restrukturierung der Arbeitsabläu- 
fe und der Organisation als ganzer fand nur selten statt (vgl. Westkämper/Sihn 
2010; Bürkardt/Seibold 2015). 
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Heute hingegen scheint es nicht mehr nur um Einzelmaßnahmen zu gehen, 
vielmehr steht auch in der Unternehmensadministration und der Forschung & 
Entwicklung das systemische Zusammenwirken der verschiedenen Glieder der 
Wertschöpfungskette im Sinne einer »systemisch integrierten Organisation« 
(Bultemeier/Boes 2013; Boes/Kämpf/Lühr 2016d) im Fokus. Zentrale Leitlinien 
sind dabei die grundlegenden Prinzipien der Lean Production. Sie sollen im fol- 
genden Abschnitt im Überblick herausgearbeitet werden, um anschließend (Ka- 
pitel 2.1.2) Grundfragen der Übertragung dieser Prinzipien auf die Angestellten- 
bereiche zu diskutieren. 


2.1.1 Das Konzept der Lean Production 


Vor dem Hintergrund einer vielfach - in der industriellen Praxis wie in der 
Wissenschaft - geteilten Auffassung, dass das tayloristische Rationalisierungs- 
paradigma an seine Grenzen stoße, erhielt die Diskussion ab Mitte der 1980er 
Jahre wesentliche Impulse durch die Identifikation neuartiger Entwicklungs- 
pfade in der industriellen Produktion,' wobei die Produktionsmodelle in der 
japanischen Automobilindustrie vor allem durch die einflussreiche Studie von 
James Womack und Kollegen (1991) besonders viel Aufmerksamkeit auf sich zo- 
gen und unter der Losung Lean Production den Status eines Leitbilds erreichten 
(vgl. zur japanischen Automobilindustrie auch Ohno 1993; Takeda 2009; Rother 
2009; Überblicke zur Rezeption in der Industriesoziologie bieten z.B. Jürgens 
2013; Holweg 2007). 


Systemische Integration als neues Paradigma 

Der Kern des mit der Lean Production verbundenen Umbruchs in der Produk- 
tionsorganisation liegt in der konsequenten Prozessorientierung und systemi- 
schen Integration der gesamten Wertschöpfungskette - von der Entwicklung 
bis zur Auslieferung des Produkts an den Kunden. Jedes einzelne Glied der 
Kette und auch das Zusammenspiel der Kettenglieder soll mit Blick auf den 
Beitrag zur Wertschöpfung und den Nutzen beim Kunden immer wieder in 
Frage gestellt, kontinuierlich verbessert und in der Weise optimiert werden, dass 
ein effizientes, verschwendungsfreies Zusammenspiel der Teilprozesse zustande 
kommt. 


1 | Erinnert sei hier nur kursorisch an die Stichwörter »systemische Rationalisierung« 
(Altmann et al. 1986; Baethge/Oberbeck 1986) und »neue Produktionskonzepte« (Kern/ 
Schumann 1984). 
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Viele Elemente, die für die praktische Implementierung dieser Kernphi- 
losophie als erforderlich oder zumindest zweckmäßig gelten,” entstammen 
der - vielfach als nahezu mustergültig angesehenen - Realisierung im Toyota- 
Produktionssystem. Folgt man Taiichi Ohno (1993), bilden die Fließfertigung, 
die Standardisierung des Produktionsprozesses, die synchrone Taktung und die 
Just-in-time-Produktion dabei die entscheidenden strategischen Säulen. Das To- 
yota-System soll es erlauben, in Reaktion auf sich verändernde Kundenwünsche 
die Losgrößen zu vermindern - also geringere Stückzahlen in einer größeren 
Varianz herzustellen -, ohne dadurch die Kosten zu steigern; die Zielperspektive 
besteht in einer Produktion »nach Bestellung« bzw. »just in time«. Das ist in 
einer ökonomischen Weise nur realisierbar, wenn der Prozessablauf höchst eff- 
zient verkettet und verschwendungsfrei organisiert wird: Es muss sichergestellt 
sein, dass - gerade bei einem so komplexen Produkt wie einem Automobil - je- 
des Teil in erforderlicher Menge und Qualität zum richtigen Zeitpunkt für die 
Montage bereitsteht (und es also nicht erst gesucht oder beschafft werden muss), 
dass aber auch umgekehrt nicht irrationale Teile-Puffer produziert werden, die 
in Zwischenlager verbracht, aufbewahrt und wieder zurücktransportiert werden 
müssen. Idealerweise soll jeder Bedarf »just in time« aus dem Output des vorgela- 
gerten und synchron getakteten Prozessschritts befriedigt werden können, und 
zwar unter Einhaltung des Null-Fehler-Prinzips, d.h. so, dass ausschließlich ge- 
testete, qualitätsgeprüfte Teile im Prozess weitergegeben werden und damit der 
Einbau von Teilen ausgeschlossen ist, deren Fehlerhaftigkeit erst am Prozessende 
bemerkt wird. Ein so organisierter Produktionsprozess soll durch Verkürzung 
der Durchlaufzeiten, Minimierung der Lagerhaltung und des Ausschusses sowie 
Standardisierung der Prozessschritte enorme Produktivitätsvorteile gegenüber 
herkömmlichen Produktionsmodellen hervorbringen. Nach Auffassung der 
Lean-Production-Protagonisten ist eine solche Produktionsorganisation unab- 
hängig von der Industriebranche und unabhängig von nationalen Standorten 


2 | Es besteht bis heute keine Einigkeit darüber, welche Elemente zwingend sind, um 
von Lean Production zu sprechen, und welche als eher akzidentiell angesehen werden 
können (vgl. dazu Monden 2012). Die Spannweite unterschiedlicher Kombinationen 
und Ausprägungen, wie sie beispielsweise in den US-amerikanischen und europäischen 
Adaptationen des japanischen Vorbilds (Transplants«) und in den unternehmensspe- 
zifischen Varianten deutscher »Ganzheitlicher Produktionssysteme« (GPS; vgl. dazu 
z.B. Spath 2003; Springer 2009; Abel/Ittermann/Steffen 2013; Kötter/Schwarz-Kocher/ 
Zanker 2015) realisiert wurden, ist groß. Wir können die Breite des Spektrums hier 
nicht entfalten, sondern konzentrieren uns auf diejenigen Aspekte, die für die aktuel- 
len Rationalisierungsprozesse der Kopfarbeit von Bedeutung sind. 


23 


Kapitel 2 


und Kulturen realisierbar — eine Position, die nicht unwidersprochen geblieben 
ist (vgl. z.B. Schumann et al. 1992; Warnecke/Hüser 1992; Minssen 1993). 

Schon bei der Entwicklung des Toyota-Systems war Ohno klar, dass ange- 
sichts der hohen Komplexität des Prozesses, der engen Kopplung der Schritte 
und der kurzzyklischen Taktung eine zentrale Planung und Steuerung dysfunk- 
tional, ja regelrecht undurchführbar sein würde. Seine Idee beruhte deshalb ers- 
tens darauf, dezentrale Regelkreise zu schaffen, in denen jeweils der Bedarf des 
nachgelagerten Prozessschritts den Nachschub aus dem vorgelagerten Schritt 
steuerte (Pull-Prinzip). Erforderlich war dazu, eine zusätzliche Informations- 
ebene einzuziehen, d.h. eine Ebene symbolischer Dokumente, mittels derer die 
Bedarfsstelle Nachschub anfordern kann und der Nachschub dann den Weg 
zur richtigen Stelle findet (ggf. zusammen mit weiteren Informationen über die 
Verwendung etc.). Im Toyota-System handelte es sich zunächst um beschriftete 
Karten - japanisch Kanbans -, später um elektronisch lesbare Karten bzw. um 
mit Strichcodes versehene Transportbehälter, schließlich um einen rein elektro- 
nischen Informationsfluss. 

In analytischer Perspektive ist das Kanban-Informationssystem ein Aspekt 
von herausragender Bedeutung, weil es den Fluss der Werkstücke noch einmal 
in einem symbolbasierten »flow of information« abbildete. Dadurch erlaubte es 
nicht nur »im Kleinen« die Pull-Steuerung in dezentralen Regelkreisen, sondern 
auch »im Großen« - auf der Ebene der Unternehmensleitung - die Modellierung 
des Produktionsprozesses insgesamt mithilfe der Informationen, die durch die 
Kanbans ohnehin anfielen. Diese Doppelstruktur von materiellen und Informa- 
tionsflüssen ist die Voraussetzung für eine neuartige Qualität der Organisation 
und Integration von Arbeitsprozessen - eine Qualität, die erstmals auch Kopf- 
arbeit für einen nicht-tayloristischen Rationalisierungsansatz zugänglich macht. 
Wir kommen darauf in Kapitel 2.2 zurück. 

Zweitens erforderte die anspruchsvolle Koordination des Prozesses, analog 
zu den dezentralen Regelkreisen des Material- und Teileflusses auch den Arbeits- 
prozess auf Werkstattebene neu zu organisieren - und zwar in erster Linie durch 
die Arbeitsteams selbst. Voraussetzung hierfür waren qualifizierte Belegschaf- 
ten, entsprechende Freiheitsgrade der Teams in der Planung und Gestaltung der 
Arbeitsaufgaben und hinreichende Anreize - z.B. durch überdurchschnittliche 
Vergütung, Arbeitsplatzsicherheit und gesicherte Aufstiegschancen -, sich en- 
gagiert am Lean-System und insbesondere am kontinuierlichen Verbesserungs- 
prozess (Katzen) zu beteiligen. 
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Teamarbeit in der Lean Production und die Folgen für die Beschäftigten 
Lean Production ist daher regelmäßig mit einer Bedeutungszunahme der Arbeits- 
teams verbunden, die (qualifikatorisch) imstande und (motivational) bereit sein 
müssen, dem höheren Grad an Verantwortung auf dem Shopfloor gerecht zu 
werden. Für die Funktionsfähigkeit des Produktionsmodells und die Einlösung 
der versprochenen Produktivitätsvorteile ist erforderlich, dass die Teams — bei 
Wegfall nennenswerter Teile des mittleren Managements - ein beträchtliches 
Maß an Selbstorganisation erreichen, dass sie sich teamintern unterstützen und 
Wissen teilen, dass sie sich flexibel auf wechselnde Anforderungen einstellen, 
dass sie Probleme im Arbeitsvollzug erkennen und selbstständig lösen und sich 
kreativ an der Fehlerbehebung und Prozessverbesserung beteiligen. Im Gegenzug 
für hohe Leistungsbereitschaft und Identifikation mit den Unternehmenszielen 
sollen die Arbeitsteams - dem Konzept nach - über breite subjektive Handlungs- 
und Entscheidungsspielräume verfügen und in diesem Sinne »empowert« sein. 

Die Beobachtung unterschiedlicher praktischer Ausformungen von Lean- 
Production-Konzepten hat allerdings gezeigt, dass die griffige Formel von einem 
Empowerment der Teams und die betriebliche Praxis beileibe nicht immer über- 
einstimmen und die Arbeitsorganisation keineswegs zwangsläufig Humanisie- 
rungseffekte nach sich zieht. Schon strukturell besteht ein Konflikt zwischen dem 
Ziel hoher Standardisierung der Arbeitsprozesse und dem Versprechen ausge- 
dehnter Verantwortungs- bzw. Autonomiespielräume (Vormbusch 1999; Babson 
1995; vgl. Wellins/Byham 1991). In der Praxis zeigt sich u.a., dass Arbeitsteams 
auch zu sich selbst kontrollierenden und sanktionierenden Organisationsein- 
heiten werden können, die durch »peer-group pressure« den Arbeitsdruck eher 
verstärken als abschwächen (vgl. dazu Vormbusch 1999; Aumann/Riezler 1993; 
Moldaschl 1994; Zimolong/Windel 1996), und dass ansteigende teaminterne 
Flexibilität durch Weiterqualifikation, Teilung von Wissen und ein breiteres Tä- 
tigkeitsspektrum der Teammitglieder ein zweischneidiges Schwert sein kann: 
Die Flexibilität kann dem Management nämlich in gewissen Konstellationen, 
z.B. bei Produktionsspitzen oder personeller Unterdeckung, auch veränderte 
Arbeitseinsatzkonzepte erlauben, die letztlich auf Kosten der Beschäftigten ge- 
hen und in ein »management by stress« münden (Götz 1997; Parker/Slaughter 
1988, 1995). Nicht zuletzt kann in den Teams Druck entstehen, ehemals privates 
Expertenwissen der Gruppe zugänglich zu machen (Vormbusch 1999). Die da- 
mit angestrebte »Kollektivierung von Wissen« (Boes et al. 2014a) kann so dazu 
führen, dass mit unverzichtbarem Spezialwissen ausgestattete Beschäftigte eine 
wesentliche Quelle ihrer »Primärmacht« (Jürgens 1984) einbüßen. 
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2.1.2 Lean-Konzepte in der Kopfarbeit 


Obwohl mittel- und hochqualifizierte Arbeit in den indirekten Bereichen der 
Unternehmen - also Aufgaben in der (Finanz- und Personal-)Administration, 
Arbeitsplanung und -vorbereitung sowie Forschung & Entwicklung - während 
des 20. Jahrhunderts beständig an Bedeutung gewonnen hatten und die Ange- 
stelltenbereiche stetig angewachsen waren (bis sie, der Kopfzahl nach, die Fer- 
tigungsbereiche vielfach überflügelten), galt die hier geleistete Arbeit - »Kopf- 
arbeit« — lange Zeit als relativ rationalisierungsresistent. Ausschlaggebend war 
die Vorstellung, dass sich Kopfarbeit eben im Kopf vollziehe, also von intellek- 
tuellen und kreativen Prozessen geprägt sei, daher »unsichtbar«, nicht planbar 
und nicht auf standardisierte Prozeduren reduzierbar sei. Die Lean-Prinzipien 
warfen ein neues Licht auf diese Anschauung. 


Zentrale Ziele und Methoden 

Ausgangspunkt von Versuchen, Lean-Konzepte auf die Kopfarbeit auszudehnen, 
ist die Feststellung, dass Prozessabläufe in den Büros intransparent seien und 
daher der Verdacht bestehe, dass sie auch ineffizient sind. Um ein zentrales Ziel 
der Lean-Philosophie - die Vermeidung von Verschwendung - zu erreichen, 
geht es demnach zuerst einmal um die Schaffung von Transparenz hinsichtlich 
der Arbeitsprozesse in den Angestelltenbereichen, um »Verschwendungsherde« 
identifizieren und eliminieren zu können. Dem systemischen Ansatz folgend, 
steht dabei weniger der Arbeitsvollzug des konkreten Einzelnen im Zentrum, 
sondern vielmehr der arbeitsteilige Prozess, in dem - so die Annahme - Poten- 
ziale für Standardisierung, Verbesserung der Schnittstellen, synchrone Taktung 
und Steigerung des Wissensaustauschs zwischen den Beschäftigten enthalten 
sind. Diese Prozessorientierung impliziert, sich auf die Kooperations- und Kom- 
munikationspraxis der Arbeitsteams zu konzentrieren, von denen angenommen 
wird, dass sie - anders als das, was unbeobachtbar in den Köpfen geschieht - auf 
gedeckt, analysiert und optimiert werden können. 

Als in der Praxis durchgängig verbreitete Lean-Methoden in den Angestell- 
tenbereichen werden insbesondere »5S«, »KVP/Kaizen«, »Wertstromanalysen« 
und das »Shopfloor-Management« beschrieben.” Dabei gelten die Einführung 
von 5S-Workshops und von kontinuierlichen Verbesserungsprozessen als »ein- 
fache Einstiegsmethoden« (Bürkardt/Seibold 2015, S. 6), die geeignet sind, die 
Beschäftigten mit den Lean-Prinzipien vertraut zu machen. Mit der 5S-Methode 
(im Deutschen auch »5A« genannt) werden der eigene Arbeitsplatz und die 


3 | Einen guten Überblick über Lean-Konzepte im Büro bieten z.B. Böhm/Gerst (2013) 
sowie Gerst (2014). 
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Arbeitsumgebung so organisiert, dass sie dem jeweiligen Arbeitsprozess optimal 
angepasst sind. Dies soll durch den Vollzug der fünf Schritte Sortieren (»sort«), 
Systematisieren (»set in order«), Saubermachen (shine«), Standardisieren (»stan- 
dardize«) und Standards einhalten und verbessern (»sustain«) erreicht werden. 
Weil dies oft kollektiv geschieht, gilt die Methode auch als ein Einstieg in die ge- 
meinsame Arbeitsplanung im Team (vgl. z.B. Productivity Press Development 
Team 2005). Beim KVP bzw. Kaizen geht es bereits um die ersten Schritte zur ge- 
meinsamen Optimierung von Arbeitsabläufen. Sie werden meist an einer eigens 
dafür eingerichteten Tafel dokumentiert. Die Beschäftigten sollen hier konkrete 
Verbesserungsvorschläge planen, testweise umsetzen, die Zielerreichung über- 
prüfen und die Lösung schließlich in einen neuen Standard überführen (vgl. 
Böhm/Gerst 2013; Brunner 2014). 

Wertstromanalysen sind ein relativ fortgeschrittenes Lean-Instrument. Hier 
geht es darum, die (wichtigsten) Arbeitsprozesse im Büro (dabei vor allem: die 
Abfolge der Bearbeitungsschritte und den »flow of information«) durch Visu- 
alisierung transparent zu machen, um sie analysieren und anschließend op- 
timieren zu können. Dabei wird unter Optimierung primär die Vermeidung 
von Verschwendung verstanden. Angestrebt werden zum einen die Stärkung 
des Denkens in Prozessen und die ganzheitliche Betrachtung von Wertschöp- 
fungsketten, zum anderen vor allem die Unterscheidung zwischen so genann- 
ten »wertschöpfenden« und »nicht-wertschöpfenden« Tätigkeiten. Der Prozess 
beginnt oft mit einer Team-Diskussion darüber, welche Tätigkeiten wirklich 
einen Kundennutzen haben - allein sie gelten als »wertschöpfend« -, um im 
Anschluss gemeinsam Möglichkeiten zur Reduzierung der übrigen, »nicht-wert- 
schöpfenden« Tätigkeiten zu entwickeln. Insbesondere im hochqualifizierten 
Bereich, etwa in der Software-Entwicklung, wird die Methode auch verwendet, 
um kollektiv Probleme im Prozessablauf zu identifizieren (vgl. Poppendieck/ 
Poppendieck 2007, S. 83 ff.). 

Das Shopfloor-Management dient vor allem dazu, die Arbeit der Teams im 
Büro transparent zu machen. Die Grundlage ist ein sog. Shopfloor-Board, auf 
dem der konkrete Arbeitsprozess und -fortschritt des Teams visualisiert wird. 
Dazu dienen Kennzahlen, die vom Management vorgegeben oder auch vom 
Team selbst entwickelt sein können, und/oder »Kärtchen«, auf denen die Auf- 
gaben der einzelnen Teammitglieder notiert und häufig mit der Dauer und einer 
Deadline hinterlegt sind. Die Teammitglieder treffen sich regelmäßig, meist täg- 
lich, am Board in sog. »Stehungen« oder »Stand-ups«, um Aufgaben zu priorisie- 
ren, Kapazitäten zu planen oder sich gegenseitig bei Problemen zu unterstützen. 
Hier wird eine kurze Auswertung der am vorherigen Tag erledigten Aufgaben 
vorgenommen und der individuelle Tagesablauf jedes Einzelnen durchgespro- 
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chen. Dadurch können die Prozesse im Team kollektiv geplant, in eine zeitliche 
Taktung integriert und die Einhaltung des Takts - gemessen an täglichen, wö- 
chentlichen und monatlichen Zielen - regelmäßig überprüft werden. Vor allem 
wird der Status des Arbeitsprozesses und -fortschritts des Teams öffentlich und 
wahrnehmbar - für alle Teammitglieder, aber auch für Vorgesetzte. Während 
die »Stehungen« und »Stand-ups« explizit der Shopfloor-Management-Methode 
aus der Lean Production entnommen sind (vgl. Suzaki 1993; Brunner 2014), wird 
insbesondere in den höherqualifizierten Angestelltenbereichen eine ähnliche 
Form der Arbeitsorganisation im Team und des kommunikativen Austauschs 
angewendet, die dort die Bezeichnung Daily Scrum trägt. Sie stammt aus dem 
Repertoire der agilen Methoden der Projektorganisation in der Software-Ent- 
wicklung, die unter dem Namen »Scrum« bekannt geworden ist (vgl. Schwaber 
2004; Beck et al. 2001; Yip 2006; Sliger 2006). 


Lean und agile Methoden in der Software-Entwicklung 

Scrum als Vorgehensmodell in der Software-Entwicklung ist gut anschlussfähig 
an zentrale Lean-Prinzipien, weil es auch hier darum geht, von einer hierar- 
chisch-bürokratischen Prozessarchitektur wegzukommen und ein ganzheitli- 
ches, flexibles und dynamisches - kurz: »agiles« - Modell anzuwenden. Die Idee 
von Scrum ging aus der Kritik am früher vorherrschenden »Wasserfallmodell« 
hervor, das von der Vorstellung geprägt ist, ein Software-Projekt zu Beginn an- 
hand eines Anforderungskatalogs exakt vorauszuplanen und in abgegrenzte, 
sequenziell zu bearbeitende Projektphasen zu zerlegen (sie werden oft als Stu- 
fen einer Kaskade vorgestellt und gaben dem Modell den Namen), die in einer 
hierarchischen Organisationsstruktur - in der Regel von einem Projektleiter 
verantwortet - linear und arbeitsteilig abgearbeitet werden. Praktisch erwiesen 
sich »Wasserfallprojekte« mit ihren langen Planungs- und teils mehrjährigen 
Projektlaufzeiten (vgl. Beck et al. 2001) oft als zu schwerfällig und wegen der in 
der Software-Entwicklung zwangsläufig vorhandenen Unwägbarkeiten und fast 
immer auftretenden Iterationserfordernisse als zu starr und unflexibel (vgl. dazu 
DeMarco 2001). 

Scrum zieht daraus die Konsequenz, von der kompletten A-priori-Planung 
und -Spezifikation des Software-Projekts abzurücken. Stattdessen werden zu Be- 
ginn die zentralen Features der Software zusammen mit dem Kunden bestimmt 
und in eine Liste von Anforderungen (den Product Backlog) überführt, die dann 
während des Projektverlaufs kontinuierlich aktualisiert wird. Die Anforderun- 
gen werden dann in User Stories konkretisiert, die den angestrebten Eigenschaften 
eine anschauliche Form geben, indem sie die zu entwickelnde Funktionalität aus 
der Perspektive des Anwenders (»User«) beschreiben. Der Entwicklungsprozess 
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selbst wird in kurzzyklische Intervalle von zwei- bis vierwöchigen Sprints unter- 
teilt, an deren Ende jedes Entwicklerteam jeweils lauffähige Software (Usable 
Software) vorlegen muss, die dann von Sprint zu Sprint schrittweise erweitert, in- 
tegriert und ausgebaut wird. Die einzelnen Items des Product Backlog werden erst 
jeweils für die einzelnen Sprints detailliert beschrieben und in eine priorisierte 
Liste von Einzelaufgaben (tasks) zerlegt - den Sprint Backlog -, deren Erledigung 
die Teams bzw. einzelne Teammitglieder übernehmen. Das kurzzyklische Vor- 
gehen wird auch auf die Meeting-Routinen der Teams übertragen: Sie sollen sich 
täglich zum Daily Scrum treffen, wo sich alle Teammitglieder gegenseitig über 
den jeweiligen Arbeitsfortschritt in Kenntnis setzen. Die schrittweise Aufgaben- 
erledigung während eines Sprints wird gewöhnlich auf einem Burndown-Chart 
visuell festgehalten. Dem Gedanken der kontinuierlichen Verbesserung trägt 
Scrum durch die Institution der Retrospektive Rechnung, ein Meeting am Ende 
eines jeden Sprints, auf dem die Teammitglieder ihre Kooperationserfahrungen 
während der vergangenen Etappe reflektieren und Optimierungsvorschläge für 
die Arbeitsweise diskutieren sollen. 

Das Scrum-Modell sieht nicht zuletzt auch neue standardisierte Rollen und 
eine veränderte Aufgabenverteilung im Projekt vor. Insbesondere die Rolle des 
klassischen Projektleiters fällt weg. Stattdessen gibt es den Product Owner, der 
gegenüber den Teams die Perspektive des Kunden vertritt und dem die Ent 
scheidung obliegt, ob definierte Anforderungen am Ende eines Intervalls als er- 
reicht gelten können. Anders als ein Projektleiter kann er jedoch formell nicht 
die Arbeitsverteilung sowie die Zeit- und Kapazitätsplanung der Entwickler- 
teams bestimmen oder kontrollieren. Genau diese Kompetenzen bleiben dem 
Team vorbehalten, weswegen es als »empowert« bezeichnet wird. Dreh- und 
Angelpunkt des Erfolgs dieser Methode ist, dass die Teams den Arbeitsaufwand 
und die dafür erforderliche Zeitdauer auf Basis ihrer eigenen Fachkompetenz 
und Erfahrung selbstständig im Voraus schätzen - und dadurch, realistische 
Schätzung vorausgesetzt, erheblichen Einfluss auf ihre Arbeitsbelastung (ihren 
»Workload«) nehmen können. Die empowerten Teams sollen also selbst über 
ihre Kapazitäten bestimmen und auf dieser Grundlage eigenverantwortlich 
agieren, wenn sie sich gegenüber dem Product Owner für die Abarbeitung eines 
bestimmten Arbeitsvolumens in einem definierten Zeitraum »committen«. Sie 
sollen demnach als Team über relativ hohe Gestaltungsspielräume in ihrer täg- 
lichen Arbeit verfügen und z.B. auch selbst entscheiden, wie sie ihre Anwen- 
dungen programmieren, mit welchen Tools sie arbeiten usw. Gerade weil dem 
Team eine tragende Bedeutung zugedacht wird, ist für die soziale Integration 
der Teams eine eigene Rolle, die des Scrum Masters, vorgesehen. 
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Die agilen Methoden à la Scrum erweisen sich insbesondere deshalb als an- 
schlussfähig an neue Lean-Konzepte, weil sie den Unternehmen auch im Bereich 
der Kopfarbeit ein Werkzeug an die Hand geben, Team- bzw. Gruppenarbeit im 
Sinne der »Rationalisierung sozialer Interaktion« (Vormbusch 1999, S. 264) neu 
zu organisieren. Umgekehrt gelang der Durchbruch der agilen Methoden in den 
Unternehmen erst, als sie mit zentralen Prinzipien von Lean ergänzt wurden 
(insbesondere mit dem Flussprinzip und der synchronen Taktung sowie mit dem 
durchgängigen »flow of information«). Die Semantik von Lean überzeugte nun 
auch das Management und gab Antworten auf die Frage, wie nicht nur einzelne 
Teams »agil« arbeiten können, sondern sich ganze Entwicklungsabteilungen mit 
mehreren Tausend Entwicklern als synchron arbeitende Wertschöpfungskette 
organisieren lassen (vgl. Boes et al. 2014a). Vor diesem Hintergrund konnte sich 
die Kombination von Lean und agilen Methoden in den großen Software-Kon- 
zernen zu einem neuen »state of the art« entwickeln und als eine neue Leit- 
vorstellung für die Software-Entwicklung herausbilden (vgl. auch Woodward/ 
Surdek/Ganis 2010; Sutherland/Schwaber 2011; Dingsoyr/Dybä/Moe 2010). 


2.2 Theoretisch-konzeptuelle Grundlagen 


Der Umbruch in der Kopfarbeit im Zuge der Übertragung von Lean-Konzepten 
und des Einsatzes von agilen Methoden steht in einem engen Zusammenhang 
mit dem gegenwärtigen Prozess der digitalen Transformation. Die zunehmen- 
de Digitalisierung von Arbeitsmitteln und -gegenständen sowie die systemische 
Integration vermittels IT-gestützter Prozesse und eines durchgängigen datenba- 
sierten Informationsflusses stellen eine neue Grundlage dar, auf der Unterneh- 
men gegenwärtig versuchen, die Arbeit in den Büros der Angestellten neu zu 
organisieren. Sie ermöglichen sowohl neue Formen der Zusammenarbeit und 
des Austausches von Wissen als auch ein ganz neues Nachdenken darüber, wie 
sich Arbeitsprozesse strukturieren und integrieren lassen (vgl. Boes et al. 2016b). 
Daran können die neuen Formen der Arbeitsorganisation im Büro anknüpfen, 
indem sie komplementäre Methoden bereitstellen, um die Arbeit der Ange- 
stellten effizient und prozessorientiert sowie in Teams und entlang des »flow of 
information« zu organisieren. Gleichzeitig ermöglichen sie durch den Einzug 
einer neuen Transparenz überhaupt erst die Öffnung der Angestelltenbereiche 
in Richtung der systemischen Integration des gesamten Unternehmens. 

Im Folgenden soll die digitale Transformation zunächst grundsätzlich aus 
einer informatisierungstheoretischen Perspektive in den Blick genommen wer- 
den, um ihre fundamentale Bedeutung für den Umbruch in der Kopfarbeit kon- 
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zeptionell einzuordnen (2.2.1). Im Anschluss daran wird argumentiert, dass sich 
auf dieser Grundlage ein neuer Typ der Industrialisierung abzeichnet, der nun- 
mehr auch die Angestellten in neuer Qualität adressiert (2.2.2) und zunehmend 
ihre bisherigen, auf der Grundlage des »Expertenmodus« als spezifische Organi- 
sationsform insbesondere hochqualifizierter Kopfarbeit beruhenden Freiräume 
bedroht (2.2.3) 


2.2.1 Produktivkraftsprung auf Basis des Informationsraums 


Um die Tragweite des mit der Digitalisierung verbundenen Umbruchs in der 
Kopfarbeit zu erfassen, muss zunächst der Gehalt und die Substanz der viel- 
fach verkündeten Parole der »digitalen Revolution« kritisch überprüft werden. 
Die Digitalisierung selbst, bei der im Kern Informationen in binäre Daten ver- 
wandelt und damit maschinenoperabel gemacht werden, ist keine neue Ent- 
wicklung mehr, und die dazugehörigen Computer sind bereits vor mehr als 70 
Jahren erfunden worden. Was ist also das grundlegend Neue der gegenwärtigen 
Entwicklungsdynamik? 


Informatisierung als konzeptionelle Perspektive - 

Der Informationsraum als gesellschaftliche Handlungsebene 

Eine rein quantitative Perspektive, die allein auf steigende Rechenkapazitäten 
verweist, greift zu kurz. Eine Perspektive der Informatisierung, die technizistische 
Verengungen vermeiden will, versteht die Nutzung von Informationssystemen 
konsequent als Teil der gesellschaftlichen Produktivkraftentwicklung und nicht 
als ein bloß technisches Phänomen (vgl. dazu grundlegend: Schmiede 1996a, b; 
Baukrowitz/Boes/Schmiede 2001; Baukrowitz et al. 2006; Boes 2005; Boes et al. 
2014b). Unser Ansatz thematisiert dementsprechend die Formen der Produktiv- 
kraftsteigerung, die an den geistigen Prozessen der menschlichen Arbeit anset- 
zen und von hier aus die Produktionsprozesse revolutionieren. 

In dieser Perspektive ist Informatisierung mehr als der bloße Einsatz von 
Informations- und Kommunikationstechnologien und (wenn wir an den Dis- 
kurs zur Industrie 4.0 denken) auch mehr als ein bloßer Ermöglicher von immer 
neuen Automatisierungsformen. Sie nimmt vielmehr einen sozialen Vorgang 
in den Blick, der zum Ziel hat, geistige Tätigkeiten und ihre Ergebnisse ande- 
ren zugänglich zu machen. In der Perspektive der Informatisierung geht es also 
um die »Entäußerung« gedanklicher Vorgänge und den historischen Prozess 
ihrer Vergegenständlichung in überindividuell verwendbaren Medien (von der 
Höhlenmalerei über den Buchdruck bis hin zu modernen Informations- und 
Kommunikationstechnologien). Insofern bedeutet Informatisierung die »Mate- 
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rialisierung des Informationsgebrauchs« (Boes 2005). Aus individuellem Wissen 
wird Information, die in Informationssystemen kollektiv bearbeitbar und zum 
Gegenstand arbeitsteiliger Prozesse werden kann. 

Eine neue Qualität der Informatisierung markiert seit den 1990er Jahren 
der Aufstieg des Internets: Es wird zur Grundlage für einen global verfügbaren 
digitalen »Informationsraum« (Baukrowitz/Boes 1996), der eine neue Phase ein- 
läutet und als Grundlage für einen regelrechten Produktivkraftsprung die In- 
formatisierung zum Zentrum und Motor der Entwicklung der Produktivkräfte 
macht. 

Die Grundlage des sich mit dem Aufstieg des Informationsraums abzeichnen- 
den Produktivkraftsprungs besteht darin, dass eine neue gesellschaftliche Hand- 
lungsebene entstanden ist. Das unterscheidet den Informationsraum grundlegend 
von den Informationssystemen der Vergangenheit. Während es bei den Compu- 
tersystemen bisher lediglich um eine Interaktion zwischen Mensch und Maschi- 
ne ging, eröffnet der Informationsraum eine neue Qualität der Interaktion zwi- 
schen Menschen. Sie können hier Informationen nicht einfach nur speichern, 
bearbeiten und austauschen, sondern sie können zugleich offen und lebendig 
miteinander interagieren und auf vielfältigste Art und Weise in Beziehung tre- 
ten. Der Informationsraum wird so zu einem »sozialen Handlungsraum« (Boes 
1996), in dem sich unterschiedlichste Formen des sozialen Handelns vollziehen 
können (vgl. auch Dolata/Schrape 2013). Dies wird dadurch ermöglicht, dass der 
Informationsraum - anders als die Informationssysteme des Fordismus - letzt- 
lich verwendungsoffen ist: Die Wirklichkeit dieses sozialen Raums ist nicht »vor- 
programmiert«, sondern er verändert seine Struktur und die von ihr eröffneten 
Handlungsmöglichkeiten durch das praktische Tun der Nutzer. Er ist daher in 
seinem Wesen nicht Infrastruktur zum Transport von Informationen, sondern 
ein offener Raum, der sich erst durch das soziale Handeln seiner Nutzer konsti- 
tuiert (Baukrowitz/Boes 1996). 


Der Informationsraum als neues Fundament 

von Arbeit und Wertschöpfung 

Der Informationsraum bildet zunehmend auch das Fundament moderner 
Arbeits- und Wertschöpfungsprozesse. Zum einen wird er zum neuen »Shop 
Floor« von Arbeit: Weite Teile von dem, was Menschen in der Arbeit tun und 
wie sie mit Kollegen zusammenarbeiten, finden direkt oder indirekt in diesem 
Raum statt. In dem Maße, wie Arbeitsgegenstand und -mittel digitalisierbar 
sind, entsteht hier ein »neuer Raum der Produktion« (Boes 2004). Gerade weil 
er ein sozialer Handlungsraum ist, können hier nicht nur Abläufe und Prozesse 
entlang des »flow of information« organisiert werden, sondern auch neue For- 
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men der Kollaboration und des Austauschs von Wissen. In diesem neuen Raum 
wird Arbeit dabei in bisher ungeahnter Weise transparent. Damit werden so- 
wohl Innovations- und Lernschleifen und eine neue Qualität der Nutzung geis- 
tiger Produktivkräfte ermöglicht als auch eine immer engermaschige Kontrolle 
selbst von hochqualifizierter Angestelltenarbeit. 

Zum anderen entstehen im Zuge der digitalen Transformation ganz neue 
Leitvorstellungen der Organisation von Wertschöpfung: Die Art und Weise, wie 
Unternehmen und Wertschöpfungsketten als Ganzes funktionieren, verändert 
sich. Strategische Suchprozesse in den Unternehmen deuten darauf hin, dass vie- 
le von ihnen gerade dabei sind, sich neu zu erfinden - sie sind auf der Suche nach 
einem neuen Bauplan für das Unternehmen der Zukunft. Der alte Bauplan des 
»bürokratischen Unternehmens« verliert an Bedeutung (vgl. Boes et al. 20162). 
Statt auf eine Abschottung der funktionalen »Silos« und den »Autismus« der 
Teileinheiten setzen die Unternehmen nun auf eine »systemische Integration«, 
die die Wertschöpfungsprozesse miteinander vernetzt und zueinander in Bezie- 
hung setzt. Die Idee durchgängiger Wertschöpfungsprozesse begreift alle funk- 
tionalen Teileinheiten als Momente eines interdependenten Systems, dessen Ziel 
es ist, am Ende einen Kundennutzen zu bewirken. Voraussetzung für die syste- 
mische Integration ist der digitale »flow of information« im Informationsraum. 
Er bildet gewissermaßen das »Rückgrat« durchgängiger und vernetzter Wert- 
schöpfungsprozesse in den und außerhalb der Unternehmen. 

Zu einem zentralen Ankerpunkt im Neuerfindungsprozess der Unterneh- 
men ist die Leitvorstellung einer »agilen Organisation« (Boes et al. 2016a) gewor- 
den. Lange Planungsvorlaufzeiten, starre bürokratische Abläufe und Entschei- 
dungsprozesse sowie mehrjährige Innovations- und Entwicklungsprojekte kann 
sich angesichts der rasanten Veränderungsdynamik der Märkte und Technolo- 
gien kein Unternehmen mehr leisten. Agilität im Sinne einer neuen Beweglich- 
keit und Anpassungsfähigkeit lautet deshalb die Antwort der Unternehmen auf 
diese Herausforderung der Digitalisierung. Agilität setzt eine neue Transparenz 
bis auf die Ebene der einzelnen Mitarbeiterinnen und Mitarbeiter voraus. Der 
Informationsraum ermöglicht diese Transparenz; bis in die feinsten Verästelun- 
gen der Organisation sind permanent Daten und Informationen in Echtzeit ver- 
fügbar (Boes/Bultemeier 2008; Boes et al. 2015). 

Der gemeinsame Hintergrund der skizzierten Veränderungen in den Ar- 
beits- und Wertschöpfungsprozessen besteht in einer neuen Dominanz der In- 
formationsebene. Mit der digitalen Transformation wird die Informationsebene 
zum strategischen Zentrum von Wertschöpfungsprozessen und zur direkten 
Eingriffsebene der Organisation von Arbeit. Auf dieser Grundlage gewinnt 
schließlich ein »neuer Typ der Industrialisierung« (Boes 2004; vgl. Boes/Kämpf 
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2012) an Konturen. Dessen Ausgangspunkt bilden nicht länger die klassischen 
Maschinensysteme, sondern vielmehr die Informationsebene und der digitale 
Fluss von Informationen und Daten. 


2.2.2 Zwei Begriffe der Industrialisierung von Arbeit 


In Hinsicht auf den skizzierten Produktivkraftsprung hat der Informations- 
raum das Potenzial, für die Entwicklung von Arbeit im 21. Jahrhundert das zu 
werden, was die Maschinensysteme der »großen Industrie« (Marx) für die Öko- 
nomie im 19. und 20. Jahrhundert waren. Um zu verstehen, wie sich davon aus- 
gehend die Wissensarbeit und ihre Organisation verändern, müssen wir auch in 
grundlegender Perspektive neu über Industrialisierung nachdenken. Dies setzt 
nicht nur ein fundiertes und differenziertes Industrialisierungsverständnis vo- 
raus, sondern insbesondere auch seine Verknüpfung mit der informatisierungs- 
theoretischen Perspektive. 


Industrialisierung als objektiver Prozess 

Einen fruchtbaren Ausgangspunkt für ein profundes Verständnis von Industria- 
lisierung bieten nach wie vor Marx’ Überlegungen zur »großen Industrie«. Marx 
entwickelte den Begriff der »großen Industrie« in Abgrenzung zum noch hand- 
werklich geprägten Produktionsmodus der Manufaktur. Dabei arbeitete er he- 
raus, dass die Manufaktur mit ihrer hoch arbeitsteiligen Organisation die Basis 
für die Industrialisierung der Produktion gelegt hat, die durch den verstärkten 
Einsatz neuartiger Maschinen vollendet wurde. So wurde es möglich, die struk- 
turellen Grenzen der Rationalisierung in der Manufakturphase zu überwinden, 
die in der Abhängigkeit vom Geschick des einzelnen Handwerkers bestanden. 
Mit der Integration der Maschine in den Arbeitsprozess bildete sich ein histo- 
risch neuer Rationalisierungsmodus heraus, der nicht mehr bei der Tätigkeit, 
sondern am Werkzeug ansetzt: »Die Umwälzung der Produktionsweise nimmt 
in der Manufaktur die Arbeitskraft zum Ausgangspunkt, in der großen Indus- 
trie das Arbeitsmittel.« (Marx 1972 [1867], S. 391) 

Wesentlich für die Durchsetzung des neuen Produktionsmodus der gro- 
ßen Industrie war aber nicht die einzelne Maschine, sondern das Maschinen- 
system. Diese Form der Organisation des Produktionsprozesses setzte ent- 
wicklungslogisch auf der Spezialisierung in der Manufakturphase auf. Doch 
die Organisation des Produktionsprozesses mit Hilfe der neuartigen Maschi- 
nensysteme erzeugte eine qualitative Veränderung gegenüber der vorherigen 
Phase: 
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»Indes tritt sofort ein wesentlicher Unterschied ein. In der Manufaktur müssen Arbei- 
ter, vereinzelt oder in Gruppen, jeden besondren Teilprozeß mit ihrem Handwerks- 
zeug ausführen. Wird der Arbeiter dem Prozeß angeeignet, so ist aber auch vorher der 
Prozeß dem Arbeiter angepaßt. Dies subjektive Prinzip der Teilung fällt weg für die 
maschinenartige Produktion. Der Gesamtprozeß wird hier objektiv, an und für sich 
betrachtet, in seine konstituierenden Phasen analysiert, und das Problem, jeden Teil- 
prozeß auszuführen und die verschiednen Teilprozesse zu verbinden, durch technische 
Anwendung der Mechanik, Chemie usw. gelöst, wobei natürlich nach wie vor die theo- 
retische Konzeption durch gehäufte praktische Erfahrung auf großer Stufenleiter ver- 
vollkommnet werden muß.« (Ebd., S. 400 f.) 


Zwar überschätzte Marx hier den realen Stand der Verwissenschaftlichung der 
Produktionsprozesse, wie Braverman (1977) bemerkte, aber er erfasste die ent- 
scheidende qualitative Veränderung des Übergangs von der Manufaktur zur 
großen Industrie: Der Arbeitsprozess wird aus einem »subjektiven« Prozess, der 
ausgehend vom individuellen handwerklichen Geschick des Arbeiters konzi- 
piert war, zu einem »objektiven« Prozess, der - gedanklich vorweggenommen 
und in Form des Maschinensystems materialisiert - den Beschäftigten als »Be- 
dingung« des Arbeitsprozesses gegenübertritt. Dieser Lesart folgend markiert 
die Verwandlung eines »subjektiven« in einen »objektiven« Prozess den inne- 
ren Kern der Industrialisierung - unabhängig von ihrer konkreten historischen 
Form. Industrialisierung bedeutet also nach Marx, einen Produktionsprozess 
vom Geschick und vom Willen einzelner Individuen loszulösen, ihn mit wissen- 
schaftlichen Methoden in einen »objektiven« Prozess zu verwandeln und diesem 
in der Praxis der Arbeitsprozesse Wirkmächtigkeit zu verleihen (vgl. dazu auch 
Boes/Kämpf 2012, S. 317 ff.). 


Industrialisierung als Rationalisierung einzelner Arbeitsschritte 

Ein anderes Verständnis des Industrialisierungsbegriffs bietet Frederick Taylor, 
dessen Überlegungen zur »wissenschaftlichen Betriebsführung« (Taylor 1911) 
die Diskussion über die Industrialisierung sowohl in der Praxis als auch in der 
Wissenschaft entscheidend geprägt haben (vgl. Schmidt 2013; dazu insbeson- 
dere Braverman 1977). Anders als Marx setzt er mit seinem Rationalisierungs- 
konzept allerdings weiterhin an der Tätigkeit statt am Arbeitsmittel an. Sein 
Konzept basiert auf drei Grundprinzipien: der Loslösung des unmittelbaren 
Arbeitsprozesses von den individuellen Fertigkeiten des Arbeiters, der Trennung 
von Planung und Ausführung und schließlich der umfassenden Kontrolle der 
Ausführung eines jeden einzelnen Arbeitsschritts. Die Basis hierfür bildet eine 
detaillierte Beobachtung und wissenschaftliche Analyse der einzelnen Schritte 
des Arbeitsprozesses, woraus sich - wie Taylor glaubte - eine ideale Lösung, der 
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»one best way« ermitteln lasse. Entscheidend dabei ist, dass Taylor weiterhin am 
einzelnen Arbeitsschritt statt, wie Marx, am übergeordneten Prozess ansetzte. 
Dies erklärt letztlich auch, warum sich die tayloristischen Strategien im Bereich 
insbesondere der hochqualifizierten Kopfarbeit in der Vergangenheit als Sack- 
gasse erwiesen: So sind wesentliche Momente der geistigen Lösungsfindung 
weder vollständig planbar noch lassen sich geistige bzw. »kreative« Tätigkeiten 
von »außen« beobachten - sie blieben für die Taylor’schen Betriebsingenieure 
deshalb immer eine Art »Black Box«. 

Die vereinfachende Gleichsetzung von Taylorisierung mit Industrialisierung 
und das gleichzeitige Scheitern der tayloristischen Rationalisierungskonzepte 
in der Kopfarbeit haben insbesondere in den Sozialwissenschaften den Mythos 
einer prinzipiellen Nicht-Industrialisierbarkeit von Kopfarbeit genährt (vgl. z.B. 
Berger/Offe 1981). Die grundlegenden Arbeiten von Marx zur großen Industrie 
hingegen eröffnen eine andere Perspektive. Das Wachstum geistiger Tätigkei- 
ten lässt sich dann als Moment eines fortschreitenden gesellschaftlichen Indus- 
trialisierungsprozesses fassen (vgl. dazu auch Hack/Hack 1985). Begreift man 
Industrialisierung in diesem Sinne als Verwandlung eines subjektiven in einen 
objektiven Prozess, ist der Begriff nicht per se auf Handarbeit und die klassische 
Fertigung beschränkt, sondern lässt sich auch auf Bereiche der Kopfarbeit an- 
wenden (vgl. ausführlich Boes/Kämpf 2012; Boes et al. 2014a). In den Fokus gerät 
damit die zentrale Frage, unter welchen Bedingungen und in welcher Form sich 
geistige Tätigkeiten in einen objektiven Prozess eingliedern bzw. organisieren 
lassen. Um dies zu verstehen, müssen wir zunächst das Verhältnis von Hand- 
und Kopfarbeit näher betrachten. 


Neuer Typ der Industrialisierung 

Es wird oft übersehen, dass die »große Industrie« nicht nur die Industriearbeit 
als neue dominante Form gesellschaftlicher Arbeit hervorbrachte. Mit der Tren- 
nung von Planung und Ausführung bildete sie ebenso die Grundlage für die 
Trennung von Hand- und Kopfarbeit und erzeugte ein schnelles Wachstum 
verschiedener Formen der Kopfarbeit. Denn damit aus Handarbeit ein objekti- 
ver Prozess werden kann, muss erst einmal Kopfarbeit geleistet werden (Boes/ 
Kämpf 2012): Unabdingbar ist erstens, Informationen und Wissen über den 
Arbeitsprozess zu sammeln sowie sich die Erfahrungen der Beschäftigten anzu- 
eignen, um darauf aufbauend und unter Verwendung wissenschaftlicher Metho- 
den überhaupt einen objektiven Prozess zu entwickeln und diesen fortwährend 
zu rationalisieren. Zweitens ist die Sphäre der Kopfarbeit insbesondere für die 
Kontrolle und Steuerung des Produktionsprozesses jenseits der unmittelbaren 
Anschauung verantwortlich und bringt dazu immer komplexere Informations- 
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systeme hervor (vgl. Baukrowitz/Boes 1996). Somit hatte die Industrialisierung 
der Handarbeit schon immer eine zwangsläufige Entsprechung im schnellen 
Anwachsen der Zahl der angestellten Kopfarbeiter (vgl. z.B. Bahrdt 1958; Kocka 
1981; Braverman 1977). 

Die historische Voraussetzung dieser Entwicklung ist die Informatisierung 
der Arbeit. Sie bildet so etwas wie die »Unterseite« oder das versteckte Funda- 
ment der Industrialisierungsentwicklung. Denn das Verhältnis zwischen Hand- 
und Kopfarbeit ist wesentlich durch Informationen vermittelt. Die Kopfarbeiter 
planen den Arbeitsprozess in gesonderten Organisationseinheiten (z.B. Be- 
triebsorganisation, Arbeitsvorbereitung) und übersetzen ihn in Informationen, 
die dann wiederum der Gestaltung der Maschinensysteme sowie den organisa- 
torischen Prozessen und Vorgaben zugrunde liegen, mit denen die Handarbeiter 
konfrontiert sind. Mit dem Aufstieg des Informationsraums hat sich das Verhält- 
nis von »Unterseite« und »Oberseite« der Produktivkraftentwicklung allerdings 
umgekehrt. Die neue Dominanz der Informationsebene hat die alte Dominanz 
der stofflichen Welt der Maschinensysteme abgelöst und somit die Basis für die 
Herausbildung eines neuen Industrialisierungstyps im Zuge der digitalen Trans- 
formation gelegt. 

Der neue Typ der Industrialisierung ermöglicht nicht nur die Neuindus- 
trialisierung der Handarbeit im Zuge einer Revolutionierung der industriellen 
Fertigungsprozesse auf der Grundlage der Informationsebene und des digi- 
talen Flusses von Informationen und Daten. Die neue Dominanz der Infor- 
mationsebene wird auch zu einer neuen Grundlage, geistige Tätigkeiten und 
die Wissensarbeit selbst zunehmend in neuer Qualität zum Gegenstand von 
Industrialisierungsprozessen zu machen. Einerseits dienen IT-basierte Prozesse 
und Informationssysteme als ein »digitales Fließband«, das Kopfarbeit entlang 
eines objektiven Prozesses strukturiert; andererseits ermöglichen es die infor- 
matorische Durchdringung der Arbeitsmittel und -gegenstände im Zuge ihrer 
Digitalisierung sowie der Charakter des Informationsraums als neuer »Raum 
der Produktion«, Angestelltenarbeit einer genauen Beobachtung, Messung und 
datenbasierten Auswertung zu unterziehen, um sie anschließend wissenschaft- 
lich zu veredeln. Zusammen mit dem Kitt neuer Organisationskonzepte in den 
Büros ermöglicht die Informatisierung so neue Formen der Industrialisierung 
von Kopfarbeit, die die Welt der Büros mehr und mehr Teil einer getakteten 
Wertschöpfungskette werden lassen, in der die traditionellen individuellen »Si- 
los« der Angestellten von einer zunehmenden Transparenz und Prozessorientie- 
rung abgelöst werden. Damit schwinden nicht zuletzt auch die - insbesondere 
in hochqualifizierten Feldern sehr ausgeprägten - typischen Freiheitsgrade der 
Angestellten. 
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2.2.3 Druck auf den Expertenmodus 


Die Arbeit der Angestellten war im oben beschriebenen Sinn zwar immer schon 
integrales Moment der Rationalisierungsprozesse in der Handarbeit, doch be- 
fanden sich die Angestellten selbst lange auf einer Art »Insel«, die sie vor den Ef- 
fekten der Industrialisierung schützte. Daraus resultierte nicht nur eine soziale 
Distinktion von den »normalen« Arbeitern - die in der Soziologie viel beachtete 
typische Mentalität der Angestellten (vgl. für einen Überblick Oberbeck 2013) -, 
sondern auch ein spezifischer Reproduktionsmechanismus auf Basis einer re- 
lativ privilegierten betrieblichen Stellung und entsprechender Freiheitsgrade 
sowie Autonomiespielräume in der Arbeitsorganisation, den wir als »Experten- 
modus« (Boes et al. 2014a) bezeichnen. 


Spezifische Stellung der (hochqualifizierten) Angestellten 

im Arbeitsprozess 

Die Reichweite des Expertenmodus variiert historisch mit dem Entwicklungs- 
grad der Produktivkräfte respektive der Informatisierung sowie mit dem kon- 
kreten Charakter der Tätigkeit und dem jeweiligen Grad der Qualifikation. So 
beschreibt z.B. Kracauer (1971, S. 12f.) in seiner berühmten Sozialreportage für 
Teile der einfachen Industrieangestellten bereits in den 1920er Jahren »das Ein- 
dringen der Maschine und der Methoden des »fließenden Bandes in die An- 
gestelltensäle der Großbetriebe«, während etwa Baethge und Oberbeck (1986) 
in den 1980er Jahren für die Mehrheit der kaufmännisch-verwaltenden An- 
gestellten eine Schwächung ihrer betrieblichen Position durch neue Kontroll- 
möglichkeiten im Zuge des Computereinsatzes feststellten. Daher erscheint der 
Expertenmodus heute vor allem als eine spezielle Organisationsform der hoch- 
qualifizierten Kopfarbeit (vgl. ausführlich Boes/Kämpf/Lühr 2016d). 

Der Expertenmodus ist wesentlich dadurch gekennzeichnet, dass die Kopf- 
arbeiter über vergleichsweise große individuelle »Ungewissheitszonen« (Crozier/ 
Friedberg 1979) und spezifische Freiheitsgrade in der Arbeit verfügen. Denn in- 
sofern die Tätigkeit der Kopfarbeiter ausgehend vom konkreten Individuum ge- 
dacht und organisiert wird, bleiben die einzelnen Abläufe für Außenstehende 
eine Art »Black Box«, sodass sie sich einer direkten Kontrolle durch das Ma- 
nagement entziehen. Dementsprechend etablierte sich mit der »verantwort- 
lichen Autonomie« eine Alternative zum tayloristischen Kontrollverständnis 
(vgl. Friedman 1977). Sie verzichtet weitgehend auf die direkte Kontrolle des 
Arbeitshandelns und setzt vielmehr auf die generelle Freisetzung von Leistungs- 
bereitschaft, erfordert damit allerdings auch eine stärkere Rücksichtnahme auf 
die Interessen der Beschäftigten. Insofern stellt sie faktisch einen Tribut an die 
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spezifischen »Primärmachtpotenziale« (Jürgens 1984) der hochqualifizierten 
Angestellten dar, die aus der Abhängigkeit der Unternehmen von ihrer Quali- 
fikation und ihrer Kooperationsbereitschaft resultieren (vgl. auch Marrs 2010). 

Zum Expertenmodus gehört weiter eine spezifische Form der betrieblichen 
Integration durch Privilegierung hinsichtlich des Gehalts, der Qualifizierung 
und der Sicherheit des Arbeitsplatzes (inkl. entsprechender Aufstiegsmöglich- 
keiten), die eine dauerhafte Bindung an das Unternehmen begründet (vgl. Baeth- 
ge/Denkinger/Kadritzke 1995). Zentraler Unterschied gegenüber der normalen 
Lohnarbeit ist dabei, dass diese Privilegien nicht durch eine besondere subjektive 
Anstrengung erlangt werden, sondern gleichsam selbsttätig aus der objektiven 
Funktion im Verwertungsprozess resultieren. Mallet (1972, S. 84ff.) sprach daher 
von einer »objektiven Integration«, die aus einer Veränderung der Arbeitsorganisa- 
tion resultiert und quasi durch die Produktionsbedingungen selbst auferlegt wird. 

Aus ihrer spezifischen Stellung im Arbeitsprozess ergeben sich nicht zuletzt 
auch Implikationen für die sozialstrukturelle Einordnung der hochqualifizier- 
ten Angestellten. So lassen sie sich mit dem amerikanischen Soziologen und 
Klassentheoretiker Erik Olin Wright (2000, S. 18f.) als Repräsentanten einer 
spezifischen »privilegierten Aneignungsposition innerhalb von Ausbeutungs- 
beziehungen« begreifen. Anders als andere Angehörige der lohnabhängigen 
Mittelschichten verfügen die hochqualifizierten Angestellten über eine gewisse 
Machtposition im System der gesellschaftlichen Arbeitsteilung.* Sie resultiert 
aus einer partiellen Kontrolle über die Produktivkräfte: Zum einen kontrollie- 
ren sie durch ihre spezifische Ressource - das an die konkrete Person gebundene 
Expertenwissen - ihren eigenen Arbeitsprozess und damit die Verausgabung 
ihrer Arbeitskraft. Zum anderen nehmen sie im Rahmen ihrer Funktion bei der 
Verwissenschaftlichung der Produktion eine besondere Stellung in der betrieb- 
lichen Hierarchie ein, indem sie mit ihrer Tätigkeit faktisch zur Kontrolle und 
Steuerung der Handarbeit beitragen (vgl. Braverman 1977). 

Insofern begründet der Expertenmodus eine spezifische Stellung vor allem 
der hochqualifizierten Angestellten im Arbeitsprozess, die auf der Abhängig- 
keit der Unternehmen vom konkreten Individuum und dessen Subjektivität 
bzw. von dem an die konkrete Person gebundenen Expertenwissen basiert. Sie 
können daher im Prinzip nur formell als Lohnabhängige begriffen werden (vgl. 
Boes/Kämpf 2012). Der Warencharakter ihrer Arbeitskraft ist in dem Maße ein- 


4 | Wright selbst bezieht sich hier auf eine »strategische Stellung« in der Produktion 
sowie auf dem Arbeitsmarkt (Wright 2000a, S. 18) - was er als »strukturelle Macht« zu- 
sammenfasst (vgl. Wright 2000b; vgl. die daran angelehnten Begriffe der »Produktions- 
macht« und »Marktmacht« bei Silver 2005, S. 30 ff.). 
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geschränkt »dekommodifiziert«), wie der Grad der Austauschbarkeit des Einzel- 
nen reduziert ist, weil das Unternehmen auf ihn angewiesen ist. 


Strukturwandel von Arbeit 

Mit dem Aufstieg des Informationsraums und der Herausbildung eines neuen 
Typs der Industrialisierung kommt es nun allerdings zu einer Erosion des Exper- 
tenmodus auch in seiner letzten Bastion - der hochqualifizierten Kopfarbeit. Die- 
se Entwicklung ist zunächst quantitativ getrieben: durch das massive Anwachsen 
der Zahl hochqualifizierter Beschäftigter in den zunehmend verwissenschaftlich- 
ten und akademisierten Wirtschaftssektoren. Die frühere »Sonderrolle« der be- 
trieblichen Experten gerät allein wegen dieses »Massenphänomens« unter Druck. 

Ein Indiz für diese Entwicklung ist der Anstieg der Studierendenzahl (in 
Deutschland: von etwa 100.000 in den 1950er Jahren auf aktuell ca. 2,5 Mio.). 
Die im tertiären Bildungssystem produzierten Akademiker finden sich nicht nur, 
aber wohl zu einem großen Teil als hochqualifizierte Angestellte in den Betrie- 
ben wieder. Auch die massive Zunahme der Beschäftigtenzahl in ITK- bzw. »In- 
formationsberufen« weist in diese Richtung (vgl. z.B. Dostal 1995; Will-Zocholl/ 
Kämpf 2016). Informatiker etwa sind als Software-Entwickler nicht allein in der 
vergleichsweise jungen IT-Branche beschäftigt, sondern ebenso in den sog. »in- 
direkten Bereichen« traditioneller Industrien, im Maschinen- und Fahrzeugbau, 
in der Telekommunikation und den Finanzdienstleistungen oder in der Elektro- 
technik (vgl. z.B. Friedewald et al. 2001). Siemens gibt beispielsweise an, heute 
allein in der Industriesparte 8.000 Software-Entwickler zu beschäftigten - vier- 
mal mehr als vor zehn Jahren. Auch im mittelständisch geprägten Maschinen- 
bau lässt sich beobachten, dass sich das zahlenmäßige Verhältnis der Beschäftig- 
ten in den Werkshallen zu denen in den Büros innerhalb weniger Jahre geradezu 
umgekehrt hat - heute sind in einzelnen Betrieben der Branche bereits zwei 
Drittel der Beschäftigten in den indirekten Bereichen tätig. 

Mit dem Anwachsen der Zahl hochqualifizierter Angestellter in den Unter- 
nehmen vollzieht sich schließlich ein dialektischer Umschlag von Quantität in 
Qualität. Der Verwertungsdruck gegenüber den Angestelltenbereichen steigt; 
die Herausforderung an das Management, die expandierende Kopfarbeit in die 
Gesamtorganisation der Wertschöpfungsprozesse zu integrieren, nimmt zu. In- 
folgedessen beginnen die Unternehmen nach Alternativen zum alten Experten- 
modus zu suchen. 


Neuorganisation der Angestelltenarbeit 


Der Druck auf den Expertenmodus resultiert jedoch nicht allein aus einer rein 
quantitativen Entwicklung, sondern hat tiefere Ursachen in der skizzierten 
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qualitativen Veränderung der Produktivkraftstruktur insgesamt. Der neue Typ 
der Industrialisierung ermöglicht es, die hochqualifizierte Kopfarbeit im Pro- 
duktionsprozess auf eine andere Art und Weise zu organisieren (vgl. auch Boes 
et al. 2016b). Geistige Tätigkeiten werden im Informationsraum als digitalem 
»Raum der Produktion« aneinander anschlussfähig gemacht und können so 
über die Grenzen von Unternehmen hinweg zu einem gemeinsamen Arbeits- 
prozess zusammengeführt werden. Dieser Umbruch wirkt sich auch auf den 
Expertenmodus aus. Analog zu den Maschinensystemen der »großen Indust- 
rie«, die einst die Handarbeit in einen kollektiven Prozess integrierten, ermög- 
licht es nunmehr der Informationsraum, auch geistige Tätigkeiten nicht mehr 
primär ausgehend vom individuellen Geschick, sondern arbeitsteilig in einem 
»objektiven Prozess« zu organisieren. Der Informationsraum ist dabei nicht 
nur die Basis für die Strukturierung und Integration der Kopfarbeit durch IT- 
Prozesse und moderne Informationssysteme, sondern wird als sozialer Hand- 
lungsraum auch immer mehr zu einer Plattform für einen komplementären 
Koordinationsmodus nach dem Prinzip der »Öffentlichkeit« (vgl. Bultemeier/ 
Boes 2013). 

War für die »große Industrie« noch ein gegenläufiger Entwicklungstrend 
von Hand- und Kopfarbeit charakteristisch, der zur Herausbildung einer ge- 
schützten »Insel« für die Angestellten führte, so wird die Kopfarbeit nun selbst 
zum Gegenstand der Industrialisierung. Die Unternehmen versuchen nun- 
mehr, den alten Expertenmodus als spezifische Organisationsform insbesonde- 
re hochqualifizierter Kopfarbeit aufzuheben oder zumindest einzuschränken, 
um die Arbeit der Angestellten austauschbar zu machen. Gerade im hochqua- 
lifizierten Bereich besteht für sie die Herausforderung darin, in Abgrenzung 
von tayloristischen Konzepten die Subjektpotenziale der Experten nicht »aus- 
zuschalten«, sondern die Subjektleistung systematisch plan- und wiederholbar 
zu nutzen. Es geht also darum, die Abhängigkeit vom einzelnen Beschäftigten 
als Person und dessen konkreter Individualität zu reduzieren, ohne jedoch auf 
die Subjektivität im Arbeitsprozess zu verzichten (Boes/Kämpf 2012). Dafür 
reichen aber die neuen Möglichkeiten auf der Basis des Informationsraums 
allein nicht aus. Die Unternehmen experimentieren daher immer mehr mit 
komplementären Organisationskonzepten in den Büros. Dabei geraten insbe- 
sondere Lean-Konzepte und agile Methoden in den Fokus, die darauf zielen, 
die Arbeit der Angestellten effizient und prozessorientiert sowie in Teams und 
entlang des »flow of information« zu organisieren. Sie sollen zudem durch 
den Einzug einer neuen Transparenz die Öffnung der Angestelltenbereiche in 
Richtung einer systemischen Integration des gesamten Unternehmens ermög- 
lichen. 
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2.3 Methodisches Vorgehen und empirische Basis 


Ausgehend von den oben beschriebenen Entwicklungstendenzen und eingelas- 
sen in den skizzierten Theorierahmen geht es in unserer Studie darum, den mit 
der Digitalisierung verbundenen Umbruch in der Organisation von Kopfarbeit 
mittels eines qualitativen Untersuchungsdesigns explorativ in den Blick zu neh- 
men. Ziel ist es, eine facettenreiche und empirisch dichte Analyse der Verände- 
rungen in drei exemplarischen Feldern zu leisten: in Verwaltungsbereichen, in 
der industriellen Forschung & Entwicklung sowie im Bereich der IT-Dienstleis- 
tungen und der Software-Entwicklung. 

Methodisch sind wir in unserem Projekt in einem zweistufigen Verfahren 
vorgegangen: In einer ersten Explorationsphase haben wir im Sinne einer empi- 
rischen Bestandsaufnahme untersucht, welche Strategien sich in den Unterneh- 
men mit den Schlagworten Lean und »Agilität« verbinden, welche Prinzipien 
und Konzepte zum Einsatz kommen, welche strategischen Zielstellungen damit 
verfolgt und welche Zielgruppen adressiert werden. Darauf folgte im zweiten 
Schritt eine vertiefende Analyse, wie die neuen Organisationskonzepte in unter- 
schiedlichen Bereichen der Kopfarbeit in der Praxis umgesetzt werden, wie sich 
die Organisation von Arbeit mit welchen Folgen für die Belegschaften verän- 
dert, wie die Beschäftigten diesen Wandel erleben und inwiefern sie veränderten 
Belastungssituationen ausgesetzt sind. 

Die empirische Basis für die erste Phase bildeten 13 explorative Kurzfallstu- 
dien, in denen umfangreiche Dokumentenanalysen (öffentlicher und interner 
Dokumente) angestellt sowie Expertengespräche, Werksbesichtigungen, Grup- 
pendiskussionen und Workshops mit insgesamt 38 Gesprächspartnern durchge- 
führt wurden. Im Zentrum standen dabei Unternehmen aus der Software-Ent- 
wicklung, den IT- und den Finanzdienstleistungen, dem Maschinenbau sowie 
der Metall- und Elektroindustrie. Die Expertengespräche (vgl. Liebold/Trinczek 
2002) wurden dabei mit unterschiedlichen betrieblichen Funktionsträgern der 
Fallunternehmen geführt; dazu gehörten Vertreter der Geschäftsführungen und 
des Managements, der Personalabteilungen sowie Mitglieder der betrieblichen 
Interessenvertretung auf verschiedenen Ebenen. Alle Expertengespräche wur- 
den elektronisch aufgezeichnet und vollständig transkribiert. 

Unsere Ausgangsannahme war durchgängig, dass sich die Strategien, Kon- 
zepte, Umsetzungsstände und Prozessverläufe zwischen den Unternehmen, aber 
auch zwischen den verschiedenen Bereichen unterscheiden würden, u.a. abhän- 
gig von den fallspezifischen Ausgangssituationen bzw. Problemkonstellationen, 
der jeweiligen betrieblichen Rationalisierungsgeschichte etc. - Aspekte, die ent- 
sprechend mit zu erheben waren. Überdies sollte danach gefragt werden, ob 
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sich hinter Lean und »Agil« in den Unternehmen lediglich Einzelmaßnahmen 
verbergen oder ob es sich um groß angelegte Reorganisationsprogramme han- 
delt, die einem ganzheitlichen und integrativen Konzept folgen. Nicht zuletzt 
interessierte uns, ob im Rahmen der Lean-Initiativen in den Fallunternehmen 
Konzepte, die ursprünglich für Fertigungsarbeit entwickelt wurden, nun ledig- 
lich auf die Kopfarbeit übertragen werden - oder ob mit den neuen Formen von 
Lean tatsächlich auch konzeptionell »neue Wege« gegangen werden, die dem 
spezifischen Charakter von Kopfarbeit gerecht werden und grundlegend neue 
Möglichkeiten der betrieblichen Organisation dieser Arbeitsbereiche und ihrer 
Innovationsprozesse eröffnen. 

Für eine vertiefende Analyse in der zweiten Stufe unseres Forschungspro- 
jekts wurden sechs Unternehmen aus der Software-Entwicklung, dem Maschi- 
nenbau sowie der Metall- und Elektroindustrie ausgewählt, in denen die Be- 
reiche Verwaltung, Forschung & Entwicklung sowie Software-Entwicklung im 
Fokus standen. Hier gehen insgesamt 190 Interviews in die Studie ein, davon 140 
Intensivinterviews mit Beschäftigten und 50 Experteninterviews, darunter auch 
Gruppendiskussionen mit Beschäftigten, Führungskräften und betrieblichen 
Interessenvertretungen. Außerdem wurden Werksbesichtigungen und Büro- 
begehungen durchgeführt sowie verschiedene Unternehmensdokumente (z.B. 
öffentliche Geschäftsberichte und Pressemitteilungen, Betriebszeitungen, aber 
auch interne Folienpräsentationen) analysiert. 

Fallstudie A behandelt ein deutsches Maschinenbauunternehmen. In die 
Fallstudie gingen sechs Intensivinterviews mit Beschäftigten und drei Experten- 
interviews sowie zwei Werksbesichtigungen und eine Dokumentenanalyse ein. 
Das Unternehmen der Fallstudie B ist ein traditioneller deutscher Konzern der 
Metall- und Elektroindustrie. Hier gingen insgesamt fünf Intensivinterviews mit 
Beschäftigten und acht Expertengespräche ein. Ein Teil der Interviews (drei In- 
tensivinterviews mit Beschäftigten und fünf Expertengespräche) wurde bereits 
zwischen 2007 und 2010 erhoben und für diese Fallstudie gründlich aufgearbei- 
tet und sekundäranalytisch ausgewertet. Zudem wurde eine Dokumentenanaly- 
se vorgenommen. Fallstudie C ist ein großes europäisches IT-Unternehmen. Die 
empirische Basis für die Fallanalyse bilden 70 Tiefeninterviews mit Beschäftig- 
ten, die wir zwischen 2010 und 2012 im Rahmen einer Begleitforschung zur Ein- 
führung von Lean im Unternehmen erheben konnten. Die Umsetzung konnte 
dabei über einen Zeitraum von fast drei Jahren mit insgesamt vier Erhebungs- 
wellen empirisch verfolgt werden. Flankierend wurden 21 Expertengespräche 
durchgeführt. Die Interviews wurden nun für die Fallstudie aufgearbeitet und 
sekundäranalytisch gründlich ausgewertet. Um den aktuellen Umsetzungsstand 
zu reflektieren, wurden 2015 weitere Expertengespräche geführt. Das Unterneh- 
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men der Fallstudie D ist ein weltweit tätiger Anbieter für Unternehmenssoftware 
und entsprechende Dienstleistungen. Insgesamt gingen hier elf Intensivinter- 
views mit Beschäftigten, vier Expertengespräche, drei Gruppendiskussionen 
und eine Dokumentenanalyse in die Auswertung ein. In Fallstudie E geht es um 
einen Forschungs- und Entwicklungsbereich eines großen, weltweit agierenden 
Industriekonzerns. In die Fallstudie gingen insgesamt zwölf Intensivinterviews 
mit Beschäftigten, sieben Experteninterviews und eine Dokumentenanalyse ein. 
Das Unternehmen in Fallstudie F ist ein Industrieunternehmen aus dem Bereich 
der Metall- und Elektroindustrie. Die empirische Basis der Fallstudie bilden 33 
Intensivinterviews mit Beschäftigten in den Bereichen Software- und Hardware- 
Entwicklung, sechs Experteninterviews sowie zwei Gruppendiskussionen, Do- 
kumentenanalysen, eine Werksbesichtigung und eine Bürobegehung. 
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3 Lean und agile Methoden in der Praxis 


Der Umbruch in der Organisation von Arbeit 
und die Folgen für die Beschäftigten 


3.1 Fallstudie A: Von der Fließfertigung zum Shopfloor- 
Management in der Forschung & Entwicklung und im Büro 


3.1.1 Unternehmenscharakteristik und Ausgangsbedingungen 


Das Fallunternehmen ist ein Maschinenbauunternehmen, das weltweit mehre- 
re Tausend Mitarbeiter beschäftigt, davon etwa die Hälfte in Deutschland. Der 
hohe Internationalisierungsgrad, der vor allem in den letzten Jahren gesteigert 
wurde, ist für ein mittelständisches und eigentlich sehr regional geprägtes Unter- 
nehmen durchaus bemerkenswert. Das Unternehmen befindet sich insgesamt in 
einer positiven wirtschaftlichen Ausgangssituation: Seit der Jahrtausendwende 
wurde die Mitarbeiterzahl nahezu verdoppelt. Auch die Wirtschafts- und Fi- 
nanzkrise in den Jahren ab 2007, die zu deutlichen Auftragseinbußen führte, 
konnte sozialpartnerschaftlich mit Kurzarbeit - und damit ohne Kündigun- 
gen - überwunden werden. 

Das Fallunternehmen zeichnet sich durch eine sozialpartnerschaftlich ge- 
prägte Unternehmenskultur aus; ihm werden gute Arbeitsbedingungen zuge- 
schrieben. Wichtiger Hintergrund hierfür ist zum einen, dass das Unternehmen 
nicht am Kapitalmarkt notiert ist. Zum anderen ist es am Markt sehr erfolgreich 
und kann wachsen. Die dadurch entstehenden Spielräume werden genutzt, um 
eine mitarbeiterorientierte Personal- und Geschäftspolitik umzusetzen. Diese 
besondere Kultur wird in allen Interviews angesprochen und ist auch am Stand- 
ort selbst unmittelbar spürbar.' Prägend sind gewachsene Vertrauensbeziehun- 
gen und eine hohe Identifikation der Beschäftigten mit dem Unternehmen. Teil 


1 | Der Standort wirkt trotz der Produktionsstätten geradezu »luxuriös« und sehr mo- 
dern. Interessant ist, dass das Unternehmen, als konservativer Maschinenbauer, die 
»moderne Arbeitswelt« regelrecht ausstrahlt. Das moderne Ambiente wirkt hier zudem 
wie ein Versprechen guter Arbeitsbedingungen. 
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dieser besonderen »betrieblichen Sozialordnung (Kotthoff/Reindl 1990) ist auch 
der Betriebsrat, der eine sozialpartnerschaftliche Strategie verfolgt. 

Auch in diesem traditionsreichen Maschinenbauunternehmen haben die 
indirekten Bereiche jenseits der Fertigung deutlich an Bedeutung gewonnen. 
So arbeiten z.B. im Bereich der Forschung & Entwicklung zum Erhebungszeit- 
punkt mehr als zehn Prozent der Belegschaft weltweit. Am untersuchten Stand- 
ort - der der Stammsitz und die Zentrale des Unternehmens ist - sind heute 
nur noch weniger als 30 Prozent der Beschäftigten als Werker in der Fertigung 
tätig. Auch die den Standort weiterhin flächenmäßig dominierenden Werkshal- 
len wirken in der Anschauung mittlerweile fast schon wie Büros mit oftmals 
digitalen Bedienungspanelen. Sie sind sehr ordentlich, sauber und wirken fast 
menschenleer. 


Die Einführung von Lean im Unternehmen 

Das Unternehmen ist ein Vorreiter-Unternehmen für die ganzheitliche und 
unternehmensweite Implementierung von Lean-Management-Konzepten. Be- 
reits Mitte der 90er Jahre wurde begonnen, in Anlehnung an den Lean-Ansatz 
ein eigenes »Ganzheitliches Produktionssystem« zu entwickeln. Dieses Konzept 
wurde »Choreo«? genannt und später zum Programm »Choreo 2.0« weiterent- 
wickelt. Choreo wurde zunächst für die Fertigung entwickelt und wird heute 
zunehmend auch in den indirekten Bereichen angewendet. 

Gestartet wurde das Choreo-Projekt Mitte der 1990er Jahre. Hintergrund 
hierfür waren nicht zuletzt eigene Erfahrungen der Geschäftsführung in Japan. 
Der Fokus der Initiativen war zunächst auf das Thema Verschwendung gerich- 
tet, mit dem Ziel, Eflizienzgewinne zu erreichen (z.B. Sortierung der Werkzeu- 
ge, Aufräumen der Arbeitsplätze) und inkrementell den Produktionsprozess zu 
optimieren. Entscheidender Schritt in diesem Prozess war schließlich die Um- 
stellung von der Standplatzmontage zur Fließfertigung. Damit wurde das neue 
Produktionssystem jenseits inkrementeller, kleinschrittiger Optimierungen zur 
Basis einer grundlegenden Umstellung des Arbeits- und Produktionsprozesses. 
Mit Choreo konnten in der Praxis rasch große Erfolge erzielt werden. Beispiels- 
weise sank die durchschnittliche Montagezeit in einzelnen Bereichen innerhalb 
von vier Jahren auf unter 30 Prozent, die produzierte Jahresstückzahl konnte im 
gleichen Zeitraum fast verdreifacht werden. Auch die Durchlaufzeit sank erheb- 
lich. Insgesamt stieg die (Flächen-)Produktivität allein im ersten Jahr nach der 
Einführung der Fließfertigung um fast 50 Prozent. 


2 | Zum Schutz der Anonymität des Untersuchungsunternehmens wurde die Bezeich- 
nung geändert. 
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Die Einführung von Choreo wurde zunächst top-down durch die Geschäfts- 
führung vorangetrieben und konsequent umgesetzt. Zur operativen Umsetzung 
wurde ein hochrangiges Kern-Team gebildet, dem neben Betriebs- und Werks- 
leitern auch die Logistik und der Betriebsrat angehörten. Zentraler Bestandteil 
der Umsetzungsstrategie war parallel eine gezielte Partizipation der Beschäftig- 
ten am Umsetzungsprozess. Dieser Beteiligungsfokus bildet nicht zuletzt den 
Hintergrund, warum man sich relativ bald von den ursprünglich engagierten 
Beratern löste: Ziel war es nun, einen eigenständigen, stärker mitarbeiterorien- 
tierten Ansatz zu entwickeln. Auf der einen Seite wurden die Mitarbeiter nun 
in die Workshops und die Auswahl und Umsetzung der Methoden konkret ein- 
bezogen. Auf der anderen Seite wurden zwischen Geschäftsführung und Be- 
triebsrat »personalpolitische Grundsätze« vereinbart, die u.a. Beschäftigungs- 
garantien und Qualifizierungsmaßnahmen umfassten, um der Belegschaft 
in diesem grundlegenden Reorganisationsprozess Sicherheit zu geben. Damit 
sollte verhindert werden, dass Beschäftigte Angst haben, sich an Optimierungs- 
und Lernprozessen wirklich zu beteiligen, weil sie ggf. befürchten müssen, »sich 
selbst wegzurationalisieren«. In der Folge wurden - so unsere Gesprächspart- 
ner - nicht wenige Beschäftigte, deren Jobs und Aufgaben durch Choreo weg- 
fielen, zu »Choreo-Umsetzungsspezialisten« umqualifiziert. 

Nachdem Choreo in der Fertigung zu einer Selbstverständlichkeit geworden 
war, wurde der Lean-Prozess schließlich seit Mitte der 2000er Jahre zweifach 
erweitert. Zum einen wurde nun begonnen, die Choreo-Ideen - wenn auch lang- 
samer - von der Produktion und Logistik auf die indirekten Bereiche auszu- 
dehnen. Zum anderen wurde Choreo zu Choreo 2.0 erweitert. Nach Unterneh- 
mensangaben zielt Choreo 2.0 vor allem darauf, die Idee der kontinuierlichen 
Verbesserung im Unternehmen in neuer Qualität zu verankern. Der Arbeits- 
alltag jedes einzelnen Mitarbeiters soll nun von diesem Meta-Ziel durchdrun- 
gen sein — eine Gesprächspartnerin argumentierte deshalb, dass es regelrecht 
um eine »Verhaltensänderung« (I-A3) gehe. In der Praxis konkretisiert sich Cho- 
reo 2.0 vor allem in der Einführung von Shopfloor-Management und der damit 
verbundenen kontinuierlichen Reflexion von Kennzahlen in den Teams. Diese 
sollen den »kontinuierlichen Fortschritt« messbar machen und zugleich zum 
Ausgangspunkt eines lebendigen Diskurses bzw. sozialen Prozesses rund um die 
Frage der Nutzung von Optimierungspotenzialen werden. 


3.1.2 Erster Schritt: Lean in der Fertigung 


Gerade weil mit der Einführung von Choreo große Erfolge in der Fertigung er- 
zielt wurden, ist es instruktiv, zunächst die damit verbundenen Veränderungen 
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in den direkten Bereichen genauer in den Blick zu nehmen. Die hier entwickel- 
ten Prinzipien und Erfahrungen bilden den Hintergrund für die anschließende 
Choreo-Einführung in den Büros und der Arbeitswelt der Angestellten im Fall- 
unternehmen. Gerade der Vergleich dieser beiden Felder erweist sich als wert- 
voll, um die neuen Lean-Ansätze in ihrer Wirkung und Bedeutung zu verstehen. 


3.1.2.1 Die Prinzipien von Choreo in der Praxis: 
Von der Standplatzmontage zu Fließfertigung und Taktung 

Mit der Einführung von Choreo wurde die Fertigung im Fallunternehmen sehr 
grundlegend reorganisiert. Ausgangspunkt war eine Fertigungsorganisation, die 
auf dem Prinzip der Standplatzmontage basierte. Konkret bedeutete dies, dass 
an jeweils einem Standplatz ein Team eine ganze Maschine von Anfang bis Ende 
baute - d.h. jeder Arbeitsschritt wurde hier sukzessive vollzogen. Der Arbeits- 
fortschritt an den einzelnen Standplätzen war - da jede Maschine ein Einzelstück 
ist- kaum miteinander synchronisiert. Nach Auskunft unserer Interviewpartner 
entstand daraus eine komplizierte Organisation, die durch hohe Intransparenz 
und »Unordnung« geprägt war. Charakteristisch dafür waren z.B. hohe Teile- 
Lagerbestände sowie die typische Suche in der ganzen Werkshalle nach benö- 
tigten Teilen. Letztlich war dieses Modell nicht nur durch Ineffizienz und Ver- 
schwendung geprägt, sondern es konnten auch Skalenerträge nur eingeschränkt 
realisiert werden. Schließlich gab es nicht »einen« Produktionsprozess, sondern 
parallel eine Vielzahl unverbundener, nicht gekoppelter Prozesse. Folgerichtig 
beschreibt einer unserer Gesprächspartner dieses System als »Manufaktur«. 

Mit Choreo wurde dieses an der Manufaktur orientierte Fertigungssystem 
in Richtung einer »systemischen Integration« überwunden. Fließfertigung, Tak- 
tung und die Einführung der Gruppenarbeit bilden die wichtigsten Momente 
der neuen Fertigungsorganisation. 

Fließfertigung: Die Einführung einer konsequenten Fließfertigung ist die 
zentrale Säule der neuen Fertigungsorganisation. Der Produktionsprozess wird 
dazu in mehrere Segmente bzw. Abschnitte mit bestimmten systematisch ge- 
planten Arbeitsschritten unterteilt. Diese werden zur Grundlage von Stationen, 
durch die jede Maschine fließt; sie wird in dieser Fließfertigung sequenziell auf- 
gebaut. An den Stationen befinden sich genau die dafür notwendigen Werkzeu- 
ge sowie »just in time« die dafür benötigten Teile. Die Fließfertigung basiert ent- 
sprechend auch auf einer neuen Qualität der Logistik und der Informatisierung 
der Produktion (Kanban). Das Informationssystem soll gewährleisten, dass an 
jeder Station zum richtigen Zeitpunkt die richtigen Teile vorhanden sind. Um 
schließlich einen echten »Fluss« der (schr großen) Werkstücke zu ermöglichen, 
war im Fallunternehmen auch eine räumliche Umstrukturierung der Werks- 
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hallen notwendig. Nicht mehr das »Chaos« der Standplatzmontage bestimmt 
nun die Szenerie, sondern ein System von Stationen, das kurze Wege aufweist 
und die aufeinander folgenden Stationen auch räumlich eng miteinander ver- 
knüpft. 

In der Literatur erscheint die Fließfertigung oftmals wie ein bloßer »Quick 
Win«, indem Verschwendung durch kürzere Wege und aufgeräumte Arbeits- 
plätze minimiert wird. In Fallunternehmen A wird jedoch deutlich, dass sich 
dahinter vor allem grundlegende arbeitsorganisatorische Veränderungen verber- 
gen. Es geht also in erster Linie nicht um die räumliche Anordnung von Ma- 
schinen, sondern um ein neues Paradigma der Organisation: Die Fließfertigung 
wird zum unmittelbaren Ausdruck für die Überführung der Produktion in 
einen »objektiven Prozess«. 

Zwei Prinzipien stehen dabei im Fallunternehmen im Vordergrund. Auf der 
einen Seite erfordert die Fließfertigung in der Praxis eine ganz neue Qualität der 
Planung und Systematisierung des Produktionsprozesses. Nur auf der Grund- 
lage einer übergeordneten Systematik lassen sich die entsprechenden Stationen 
identifizieren und definieren. Im Fallbeispiel bedeutet dies, dass nicht mehr 
jede Maschine als einzigartiges Produkt, mithin als »Projekt« gefertigt wird - 
vielmehr wird der Produktionsprozess viel unmittelbarer zur konkreten Aus- 
prägung eines dahinterliegenden Prozessmodells. Auf der anderen Seite wird 
die Fließfertigung zur Grundlage dafür, Arbeitsteilung im Produktionsprozess 
neu zu organisieren und sich den Herausforderungen eines kollektiven Wert- 
schöpfungsprozesses neu zu stellen. Erst durch den systematisierten Ablauf be- 
steht nun die Chance, die Schnittstellen zwischen verschiedenen Arbeitsschrit- 
ten oder auch Abteilungen so zu organisieren, dass »ein Rädchen ins andere 
greift«. In den Interviews wird hier immer wieder auf das Prinzip der »klaren 
Zuordnung« verwiesen und, interessanterweise, betont, dass die Fließfertigung 
notwendig gewesen sei, um bei steigenden Absatzzahlen und wachsender Orga- 
nisation die Abstimmungsprozesse und »Querbeziehungen« handhabbar zu hal- 
ten. Über die Fließfertigung und ihre Stationen erhalten die Interaktionen und 
Austauschprozesse in der Produktion nun eine klare Struktur und ein ganzheit- 
liches Bezugssystem. So entsteht schließlich eine ganz neue Qualität der Trans- 
parenz im Produktionsprozess. 

Taktung: Die Einführung der Fließfertigung ist in der Praxis eng verbunden 
mit einer Taktung der Produktion. Taktung bedeutet, dass nach einem vorge- 
schriebenen Zeitintervall das Werkstück zur nächsten Station »weiterfließen« 
muss. Ohne einheitlichen Takt gäbe es an den Stationen immer wieder einen 
Stau von parallel zu bearbeitenden Werkstücken. Gerade dies soll jedoch in der 
Praxis vermieden werden (Stichwort »one piece flow«). 
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Im Fallunternehmen wird auf vergleichsweise lange Takte gesetzt. Laut 
unseren Gesprächspartnern liegt der kürzeste Takt bei einer Stunde. Auch wenn 
betont wird, dass die Taktung nicht in erster Linie dazu dienen solle, die Be- 
schäftigten unter Druck zu setzen bzw. deren individuelle Arbeitsgeschwindig- 
keit zu erhöhen, ist sie doch mit einer Veränderung der Belastungssituation ver- 
bunden. Mit der Taktung werden zwar die Belastungsspitzen - z.B. kurz vor 
Auslieferung einer Maschine - nivelliert. Dafür entsteht allerdings die Gefahr 
einer Art von »Dauerdruck«. Entscheidend ist jedoch, dass mit der Taktung ein 
»organisatorischer Rhythmus« erzeugt wird, an dem sich die gesamte Organi- 
sation ausrichtet. Er bildet die Basis für eine Synchronisierung der Übergaben 
an den Schnittstellen und bringt so in neuer Qualität »Ordnung« in die Inter- 
dependenzbeziehungen. Durch die Taktung wird bestimmt, welche Zulieferun- 
gen und Materialien zu welchem Zeitpunkt an der jeweiligen Arbeitsstation sein 
müssen, um einen reibungslosen Fluss zu gewährleisten. Die Taktung wird so 
auch zur Basis der Transparenz in der Organisation, weil nun Störungen im Be- 
triebslauf unmittelbar sichtbar werden. 

Zugespitzt gilt, dass ohne die zeitliche Bezugsebene der Taktung auch die 
Flieffertigung im Sinne der Materialisierung des Prinzips des »objektiven Prozes- 
ses« kaum vorstellbar ist. In anderen Worten: Der einheitliche organisatorische 
Rhythmus wird zur Basis einer systemischen Organisation, die die Wertschöp- 
fung ganzheitlich denkt, Schnittstellen systematisiert und kollektive Arbeitspro- 
zesse entwickelt. 

Gruppenarbeit und Shopfloor-Management: Im Fallunternehmen wurde schließ- 
lich, nach längerer Diskussion, im Anschluss an die Fließfertigung und Taktung 
auch ein fortgeschrittenes System von Gruppenarbeit eingeführt. Hierbei - so 
betonen unsere Gesprächspartner - wurde in der Einführungsphase auf »echte« 
Gruppenarbeit gesetzt. Konkret bedeutet dies z.B., dass Gruppensprecher von 
den Gruppenmitgliedern gewählt sowie Job Rotation und eine inhaltliche An- 
reicherung der Tätigkeiten praktiziert werden. Mit Blick auf die Arbeitsorgani- 
sation ist dabei interessant, dass die Gruppen nicht automatisch bestimmten Sta- 
tionen fest zugeteilt sind, sondern mit den Werkstücken von Station zu Station 
»mitwandern«. Dabei wird deutlich, dass es bei der Fließmontage weniger um 
eine Spezialisierung (im Sinne des Babbage-Prinzips) geht, sondern vor allem 
um eine prozessgesteuerte synchronisierte Abfolge von Arbeitsschritten. 

Heute hat das Thema Gruppenarbeit insgesamt an Bedeutung verloren. 
Zwar existieren die Gruppen weiterhin, aber - so die Interpretation der Inter- 
viewpartner - die Prinzipien »echter« Gruppenarbeit werden weniger gelebt 
und nicht mehr so konsequent vorangetrieben. Im Zuge der Einführung von 
Choreo 2.0 wird das etablierte Produktionssystem mit seinen Routinen auf der 
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Arbeitsebene nun ergänzt um ein flächendeckendes Shopfloor-Management 
(siehe dazu ausführlich auch 3.1.3.2). Die für die einzelnen Gruppen relevan- 
ten Kennzahlen und auch die Arbeitsplanung werden dabei im Rahmen einer 
täglichen 15-minütigen »Stehung« gemeinsam durchgegangen und auf einem 
Board festgehalten und visualisiert. Kaskadierend und aufeinander aufbauend 
finden diese »Stehungen« dann auf allen Hierarchieebenen bis zur Werkslei- 
tung statt. Ziel ist es, eine neue Qualität von Transparenz im Werk zu schaffen, 
tagesaktuell reagieren zu können (z.B. auf Störungen) und mit Blick auf die 
Kennzahlen und die dahinterliegenden Ziele ein Bewusstsein für die Notwen- 
digkeit kontinuierlicher Verbesserung in der gesamten Organisation zu ver- 
ankern.? 


3.1.2.2 Zwischenfazit: Umbruch in der Fertigung 

Mit dem neuen, durch die Ideen von Lean geprägten Produktionssystem Choreo 
wurde im Fallunternehmen in der Fertigung ein regelrechter Umbruch ein- 
geleitet. Insbesondere der Übergang von der Standplatzmontage zur Fließfer- 
tigung erweist sich hier als ein zentraler Erfolgsfaktor. Die hierbei gemachten 
Erfahrungen und Schlussfolgerungen erweisen sich auch für das Verständnis 
der Umstrukturierung und Neugestaltung der indirekten Bereiche als sehr 
instruktiv. So lassen sich z.B. von der Standplatzmontage durchaus Parallelen 
ziehen zu den Abläufen bei klassischen »Wasserfallprojekten«, wie sie jahre- 
lang die Innovationsprozesse in der Software-Entwicklung und der klassischen 
F&E in der Industrie bestimmten. Aus dieser Perspektive lässt sich die Fer- 
tigung und Montage einer Maschine mit einem »Projekt« vergleichen, das in 
diesem Fall von einem Team von Facharbeitern bearbeitet wird. Auch hier 
gibt es einen dezidierten Start, eine entsprechende A-priori-Beschreibung der 
Funktionalitäten und vor allem ein definiertes Ende, nämlich die Auslieferung 
der Maschine an den Kunden. Auf dieses »Projektende« laufen alle Prozesse 
zu. Entscheidend ist, dass die (zeitlichen) Abläufe zwischen Projektbeginn und 
-ende, zugespitzt ausgedrückt, eine »Black Box« bleiben und oftmals über einen 
langen Zeitraum (von bis zu mehreren Wochen) vergleichsweise »ungeplant« 
verlaufen. Diese spezifische Projektförmigkeit gibt in der Arbeit den Rhythmus 
und die Ordnung vor. Im Fallunternehmen hat sich gezeigt, dass bei der Stand- 
platzmontage kurz vor der Auslieferung (ähnlich wie beispielsweise in der Soft- 
ware-Entwicklung) die Arbeitsintensität deutlich anstieg: Während am Anfang 
noch »vor sich hingearbeitet werden konnte« (A-1), mussten zum Ende oftmals 


3 | Interessanterweise argumentieren einzelne Gesprächspartner, dass das neue Shop- 
floor-Management die vormalige soziale Praxis der Gruppenarbeit »ablöst«. 
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Überstunden gemacht werden, um die termingerechte Auslieferung sicherzu- 
stellen. Die Gesprächspartner beschreiben auch, wie sich auf dieser Grundlage 
ein spezifischer »Produzentenstolz« herausgebildet hat (»die Maschine als unser 
Baby«), da man bei der Montage der Maschine von Anfang bis Ende beteiligt 
war. 

Der Vergleich zwischen einem »Projekt« und der Arbeit in der Standplatz- 
montage darf allerdings nicht überstrapaziert werden. So lässt sich der Arbeits- 
prozess als solcher in der Entwicklung natürlich weit weniger planen als in 
der Montage einer als Plan bereits durchargumentierten Maschine. Dennoch 
sind die skizzierten Parallelen doch instruktiv im Hinblick auf eine »Entmysti- 
fizierung« der Neugestaltung und Restrukturierung von geistigen Tätigkeiten. 
Offensichtlich steht man bei der Überführung der Handarbeit in einen »objek- 
tiven Prozess« mitunter durchaus vor vergleichbaren Herausforderungen wie 
bei Kopfarbeit. Dies betrifft insbesondere die Frage der systemischen Integra- 
tion der Wertschöpfung - also der organisierten Zusammenführung vieler ver- 
schiedener individueller Arbeitsprozesse in einen organischen kollektiven Pro- 
duktionsprozess. Die Art und Weise, wie die Schwierigkeiten der Integration 
»an der Oberfläche« sichtbar werden, ist dabei freilich unterschiedlich: Wäh- 
rend sich z.B. bei der Software-Entwicklung die Frage der Organisation von 
Kollektivität immer dann stellt, wenn die arbeitsteilig entstandenen Module 
verschiedener Teams zu einer lauffähigen Software integriert werden müssen, 
tritt dieses Problem in der Fertigung vor allem dann auf, wenn verschiedene 
Standplatz-Teams unkoordiniert und ungeplant Teile verbrauchen und so die 
Teile-Logistik zu immer größeren Lagerbeständen und »Flexibilitätspuffern« 
zwingen.“ 

Nicht nur mit Blick auf die Ausgangssituation (»Standplatzmontage«), die 
durch ein unkoordiniertes Nebeneinander verschiedener paralleler Arbeits- 
prozesse gekennzeichnet war, lassen sich Parallelen zur Situation in indirekten 
Bereichen ziehen. Auch die im Fallunternehmen A gewählten Lösungsschritte 
(Fließfertigung, Taktung und Gruppenarbeit) bieten interessante Anknüpfungs- 
punkte. Beispielsweise setzen neue Lean-Konzepte für die Software-Entwick- 
lung ebenfalls schr dezidiert auf die Taktung von Arbeitsschritten. Gerade mit 
Blick auf die zentrale Bedeutung der Fließfertigung in Fallunternehmen A stellt 
sich die Frage, wie und in welcher Form das Flussprinzip auch in den indirekten 
Bereichen organisiert und manifestiert werden kann. 


4 | Dies ist letztlich der Grund, warum Lagerbestände und Just-in-time-Produktion 
eine so zentrale Rolle im Kontext der Lean Production spielen. 
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3.1.3 Choreo im Büro 


Mit Blick auf den Erfolg in der Fertigung hat das Unternehmen bereits 2002/2003 
angefangen, Choreo auch in den Bürobereichen umzusetzen. Während allerdings 
in der Fertigung sehr grundlegende Veränderungen die Folge waren, lief der Ein- 
führungsprozess in der Welt der Büros zunächst sehr viel langsamer und mit 
weniger Konsequenz ab. Insbesondere der zentrale Hebel bzw. der greifbare An- 
satzpunkt - in der Montage die Fliefsfertigung -, von dem aus sich der gesamte 
Produktionsprozess wirklich neu gestalten lässt, wurde noch nicht identifiziert. 
Auch das Management scheint das Thema trotz des anfänglichen Elans nicht 
mit der gleichen Vehemenz voranzutreiben. Auch wenn bislang das Prinzip der 
»Freiwilligkeit« gilt, sind der Stellenwert und die Verbreitung von Choreo in den 
indirekten Bereichen insgesamt dennoch groß. Zudem deutet sich an, dass mit 
der Umsetzung von Choreo 2.0 das Thema in den indirekten Bereichen an Bedeu- 
tung gewinnen könnte: Mit der flächendeckenden (und sichtbaren) Einführung 
der Prinzipien des Shopfloor-Managements besteht das Potenzial, zumindest einen 
Prozess anzustoßen, der auf eine grundlegende Veränderung von Arbeit in den 
indirekten Bereichen auch jenseits bloßer inkrementeller Optimierungen zielt. 


3.1.3.1 Philosophie und Konzept 

Der Ausgangspunkt für die Einführung von Choreo ist das konstante Wachstum 
der indirekten Bereiche im Fallunternehmen. Einer unserer Gesprächspartner 
betont, dass diese Bereiche nun nicht länger als unproduktiver »Wasserkopf« 
und als reine »Verwalter« abgetan werden können, sondern ihrerseits »eigen- 
ständig Wertschöpfung betreiben« (A-1). Folgt man unseren Interviewpartnern, 
sind zugleich die Komplexität und die Veränderungsgeschwindigkeit in den in- 
direkten Bereichen erheblich gestiegen. Vor diesem Hintergrund werden nicht 
nur die Vermeidung von Verschwendung und die Erzielung von Produktivitäts- 
fortschritten, sondern auch die grundsätzliche »Beherrschbarkeit« (A-2) dieser 
Bereiche zu einer wachsenden Herausforderung für das Unternehmen. 

Die Grundidee von Choreo in den indirekten Bereichen ist, diese stärker 
auf die Prozesse und Abläufe zu fokussieren, die wirklich zur Wertschöpfung 
(value-added) beitragen. Als Wertschöpfung werden die Tätigkeiten definiert, die 
beim (internen oder externen) Kunden des entsprechenden Prozesses Nutzen 
schaffen. Die anderen Tätigkeiten, die oftmals einen großen Anteil ausmachen, 
gelten demgemäß als Verschwendung. In den Worten eines Gesprächspartners 
geht es darum, in jedem Arbeitsprozess den wirklichen »roten Faden« zu finden 
und die Arbeit und Organisation an ihm auszurichten (I-A2). In der Praxis führt 
diese Perspektive zunächst dazu, dass vor allem versucht wird, den Kernprozess 
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von waste zu befreien. Hierdurch werden schnelle positive Wirkungen erwartet. 
Ein Beispiel ist hierfür, während konzentrierter Entwicklungsphasen (etwa vor- 
mittags) auf Outlook-Benachrichtigungen zu verzichten. Betont werden auch 
die zentrale Rolle der Beteiligung der Teams und die Selbstorganisation bei 
der Optimierung der Arbeitsprozesse sowie der weitgehende Verzicht auf »vor- 
schreibende Standardisierung«. Deshalb werden von den Beschäftigten auch 
ganz neue Qualifikationen wie »Reflexionsfähigkeit« erwartet. 


reo 


Folgt man dem offiziellen Modell, erfolgt die konkrete Umsetzung von Cho- 
in der Praxis in einem vierstufigen Prozess:* 


Stufe 1 - Selbstorganisation des Einzelnen verbessern: Im Zentrum der ersten 
Phase steht die Optimierung des individuellen Arbeitsplatzes. Zentrale Stich- 
worte sind SA-Workshops, Verschwendungssuche, Zeitmanagement und Ergo- 
nomie. Wichtiger Nebeneffekt dieser Maßnahmen ist es, dass die Beschäftigten 
auf niederschwellige Art und Weise die neuen Lean-Methoden kennenlernen. 
Insbesondere im Rahmen der kollektiven SA-Workshops, die als Team durch- 
geführt werden, gibt es im Unternehmen positive Erfahrungen damit, die 
Beschäftigten für den »Geist« von Choreo zu gewinnen. 

Stufe 2 - Zusammenarbeit im Team verbessern: In der zweiten Stufe wird die 
Ebene des individuellen Arbeitsplatzes ergänzt um die zentrale Dimension 
der Kooperation im Team. Hierzu werden die Abläufe gemeinsam in den 
Blick genommen und optimiert. Im Vordergrund steht unter anderem die 
Entwicklung von Regeln, Vereinbarungen und Standards für gemeinsame 
Arbeitsprozesse im Team. Ziel ist es nicht nur, Suchzeiten zu verringern, son- 
dern auch die Kundenorientierung und die Disziplin (mit Blick auf die Ein- 
haltung der Lean-Methoden) im Team zu steigern. 

Stufe 3 - Prozesse optimieren: Im nächsten Schritt - der letztlich den zentralen 
und auch aufwändigsten Baustein bildet - werden die Wertschöpfungsprozes- 
se (auch über die Grenzen des Teams hinweg) zum Gegenstand von Choreo. 
Dazu werden Prozesse und Wertströme visualisiert und in entsprechenden 
cross-funktionalen Teams neu definiert und aufeinander abgestimmt. Auch 
die Qualifizierung der Mitarbeiter für die Prozesse ist Teil dieser Phase. Nach 
Angaben des Unternehmens ist das Ziel dabei durchaus, durch klare Verant- 
wortlichkeiten und definierte Prozesse auch die indirekten Bereiche nach den 
Ideen des »Flussprinzips« zu strukturieren. Durch kürzere Durchlaufzeiten 
sollen so die Kosten gesenkt und gleichzeitig Qualität und Kundenorientie- 
rung gesteigert werden. 


5| 
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« Stufe 4 — Steuern mit Kennzahlen: Darauf aufbauend werden schließlich zur 
Bewertung und Steuerung für die wesentlichen Prozesse in einem Team bzw. 
einer Abteilung oder einem Bereich Kennzahlen entwickelt und definiert. 
Ziel ist es, die Organisation mit Zielzuständen zu steuern und die Erreichung 
der Ziele über die Kennzahlen zu evaluieren. Die Kennzahlen sollen sich da- 
bei nicht auf globale Maßzahlen der Organisation beschränken, sondern bis 
auf die Arbeitsebene heruntergebrochen werden. Sie werden dann fortlau- 
fend auf Teamtafeln visualisiert und dargestellt. Es wird so angestrebt, die 
Selbstorganisation und Eigenverantwortung in den Teams zu steigern. 


3.1.3.2 Von Choreo zu Choreo 2.0: Shopfloor-Management als neuer Hebel 

Der Fokus von Choreo in den indirekten Bereichen lag in der Vergangenheit vor 
allem auf einer inkrementellen Verbesserung und Optimierung der Organisa- 
tion. Wirklich greifbare Maßnahmen (etwa Gruppenarbeit oder Fließfertigung), 
die einem übergeordneten Programm folgen, scheint es kaum gegeben zu ha- 
ben. Mit Choreo 2.0, das in der betrieblichen Praxis vor allem als Verstetigung 
des Ansatzes der kontinuierlichen Verbesserung beschrieben wird und in der 
Praxis vor allem auf die flächendeckende Einführung eines Shopfloor-Manage- 
ments zielt, deutet sich nun der Beginn einer neuen Phase an. 

Ausgehend von der Produktion wurde begonnen, die Methode des Shopfloor- 
Managements in der gesamten Organisation zu verbreiten. Hinter der Methode 
verbirgt sich ein interessanter Ansatz, der die Koordinationsmechanismen der 
»Öffentlichkeit« (Bultemeier/Boes 2013) mit dem Prinzip des »Steuerns nach 
Zahlen« verbindet. Organisatorische Grundlage jedes Teams wird nun ein sog. 
Shopfloor-Board, an dem sich jeden Morgen die Team-Mitglieder zur täglichen 
»Stehung« versammeln. Zwar zentriert sich der Diskurs am Board wie bei Scrum 
um den Arbeitsfortschritt des Teams und dabei auftretende Probleme, er hat 
hier aber eine andere Form: Ausgangspunkt der Diskussion ist die tägliche Über- 
prüfung und Besprechung der zentralen Kennzahlen des Teams. Im Bereich des 
Arbeitsschutzes z.B. sind wesentliche Kennzahlen die Zahl der Arbeitsunfälle 
und vor allem die Zahl der wirklich produktiv geleisteten bzw. wertschöpfen- 
den Arbeitsstunden, die beim Kunden Nutzen stiften. Diese Kennzahlen wäh- 
len sich die Teams selbst. Folgt man unseren Gesprächspartnern, sollen durch 
die diskursiven Prozesse rund um das Board die Kennzahlen - die früher oftmals 
nur bürokratischen Overhead bedeuteten, in der wirklichen Arbeitspraxis je- 
doch kaum Bedeutung hatten - »mit Leben gefüllt« werden. Sie sollen zu einer 


6 | Eine Gesprächspartnerin beschreibt dies folgendermaßen: »Da haben wir als Unter- 
nehmen einen Riesenlernprozess durchgemacht, weil, die Erwartung war immer, wenn 
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steuernden und orientierenden Instanz in den (selbstorganisierten) Teams wer- 
den. Die Boards werden darüber hinaus auch für die Arbeitsplanung des Teams 
genutzt. Im untersuchten Bereich wird beispielsweise am Board jeden Freitag in 
der Gruppe die kommende Woche geplant. 

Wichtiger Unterschied zu Scrum ist zudem, dass die »Stehungen« im Fall- 
unternehmen systematisch nach oben kaskadierend durchgeführt werden. Kon- 
kret heißt dies, dass sich jeden Tag nach den Team-»Stehungen« die Teamleiter zu 
ihrer »Stehung« an ihrem Board treffen, danach die Abteilungsleiter usw. bis hin 
zur Werksleitung. Auf diese Art und Weise werden die Kennzahlen sehr schnell 
in einem täglichen Rhythmus auf allen Führungsebenen transparent, und Pro- 
bleme können schnell nach oben eskaliert werden. Die wichtigsten Kennzahlen 
werden auch in IT-Systeme eingepflegt und damit auch unabhängig von den 
Boards für das Management offengelegt. Das Prinzip der Shopfloor-Boards wird 
so nicht nur zu einer Vermittlung von »Öffentlichkeit« und »Steuern nach Zah- 
len«, sondern auch zur Vermittlung zwischen »Selbstorganisation« und (hierar- 
chischem) Management. 

Noch ist in der Praxis offen, ob sich diese Form des Shopfloor-Managements 
als strategischer Trend oder als bloße Mode erweisen wird. In den Interviews 
heißt es sinngemäß jedenfalls, in den Abteilungen, wo man die Boards sieht, 
werde Choreo nun auch wirklich umgesetzt. Das Shopfloor-Management bietet 
dabei vor allem interessante Ansatzpunkte, um die indirekten Bereiche stärker 
in Richtung einer »systemischen Integration« zu öffnen. Auf der einen Seite 
wird hier eine ganz neue Qualität der Transparenz in den Teams erreicht. Diese 
Transparenz bezieht sich sowohl auf die Innenwelt der Teams ®Was machen die 
Kollegen im Team%) als auch auf die Sichtbarkeit nach außen: Der Arbeitsfort- 
schritt des Teams wird durch die Kennzahlen transparent. Auf der anderen Seite 


wir das [Kennzahlen] einmal gefunden und definiert haben pro Bereich, dann ist es 
das im Wesentlichen. Dann können wir uns mit denen weiter steuern. Und das ist 
überhaupt nicht so. Kennzahlen funktionieren nur dann, wenn man sie ständig wie- 
der anguckt und anpasst. Das macht natürlich die Vergleichbarkeit schwierig. Und 
wir hatten ein ausgeklügeltes Kennzahlensystem für die Produktion, das waren zum 
Schluss nur noch tote Bilder, die ausgehangen sind, die sind mit einem gewissen 
Aufwand, mit einer gewissen Automatisierung erstellt worden. Aber interessiert hat’s 
eigentlich keinen mehr. [...] Und dann haben wir gemerkt, das ist ein Holzweg. Der 
eigentliche Wert der Kennzahlen ist ihre Entstehung, weil man dann in der Diskus- 
sion über die richtigen Themen ist. Und die anschließende ständige Diskussion. Und 
das machen wir jetzt eben mit diesem Shopfloor-Management. Diese Boards da auf- 
zubauen und die zu haben, der Weg dorthin ist wertvoll. Das dann hinterher zu 
haben, eher nicht.« (A-3) 
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entsteht mit der Diskussion und Reflexion am Board nun eine neue systemati- 
sche Ebene, um auch in diesen Bereichen Planung und kollektive Lernschleifen 
in Richtung Prozessorientierung anzustoßen. 


3.1.3.3 Lean im Büro in der Praxis 

Auch wenn mit Choreo 2.0 und der damit verbundenen durchgängigen Einfüh- 
rung von Shopfloor-Management im Fallunternehmen eine gemeinsame Basis für 
die Umsetzung von Lean in den indirekten Bereichen geschaffen wurde, ist ein 
differenzierter empirischer Blickwinkel auf die Praxis notwendig. Je nach kon- 
kretem Bereich und Abteilung finden sich unterschiedliche Umsetzungsgrade 
und Schwerpunktsetzungen bei der Ausgestaltung von Lean im Fallunterneh- 
men. Anhand unterschiedlicher Fallbeispiele in den Bereichen Forschung & 
Entwicklung sowie Verwaltung soll deshalb die konkrete Umsetzung in den 
Blick genommen werden. 


Lean in Forschung & Entwicklung 

Der Bereich Forschung & Entwicklung ist im Fallunternehmen in den ver- 
gangenen Jahren markant und kontinuierlich gewachsen. Mit dem Wachstum 
des Bereichs ging auch ein spürbarer Wandel hinsichtlich seiner Organisation 
und letztlich auch seiner Arbeitskultur einher. Aus der Perspektive unserer 
Gesprächspartner ist in der Folge insbesondere eine deutliche Ausdifferenzie- 
rung von Aufgaben, Tätigkeitsbereichen und organisatorischen Abläufen und 
Prozessen zu beobachten. Analog zu den anderen Fallunternehmen - z.B. zu 
den Fallunternehmen B und C - ist so selbst in den hochqualifizierten Berei- 
chen eine zunehmende Prozessorientierung und Standardisierung zu erkennen. 
Während früher Themen und Entwicklungsprozesse ganzheitlich und mit gro- 
ßen Freiheitsgraden von einzelnen Entwicklern übernommen werden konnten, 
bestimmt heute eine deutlich größere Arbeitsteilung mit systematisch durch- 
argumentierten Prozessen die Szenerie. Die Arbeit wird nun insbesondere als 
deutlich »kurzzyklischer« (A-4) und »kleinteiliger« (A-5) erlebt. Ähnlich wie etwa 
in Fallunternehmen D wird auch das Software-Tool Jira benutzt, um die Be- 
arbeitung von Arbeitspaketen (vergleichbar einem Ticket-System) intern zu or- 
ganisieren und zu »tracken«. Mitarbeiter beschreiben dies als anonymes System 
einer bloßen »Arbeitszuweisung« (A-5). Trotz des insgesamt als positiv erlebten 
Arbeitsumfelds und einer hohen Identifikation mit der Arbeit wird in der Fol- 
ge nicht nur steigender Zeit- und Leistungsdruck thematisiert, sondern auch 
kritisch auf Fragen der Anerkennung oder des Sinns in der Arbeit verwiesen 
(mit Blick auf die Veränderung hochqualifizierter Angestelltenarbeit vgl. dazu 
bereits Boes/Kämpf 2012). 
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Diese Entwicklung bildet den Kontext für die Einführung von Lean in den 
Entwicklungsabteilungen des Unternehmens. Im Sinne einer »ersten Welle« - 
so ein Gesprächspartner - wurde relativ früh damit begonnen, die Ideen und 
Konzepte von Choreo in der Entwicklung einzusetzen. Auffallend ist dabei, dass 
in der untersuchten Abteilung die initiierten Veränderungen zunächst nicht die 
Kernarbeitsprozesse selbst betrafen und »nicht in die Tiefe gehen« (A-4), son- 
dern vor allem die »Büroorganisation« zum Gegenstand haben. In der Logik 
der Stufen des Choreo-Prozesses stehen Stufe 1 - die Selbstorganisation des Ein- 
zelnen - und Stufe 2 - die Optimierung der Zusammenarbeit im Team - im 
Vordergrund. In der Folge wurden zwar auch die Stufen 3 und 4 (Prozesse und 
Kennzahlen) adressiert - aus Sicht unserer Gesprächspartner scheinen hiermit 
jedoch keine tiefgreifenden und dauerhaften Veränderungen angestoßen wor- 
den zu sein. 

Hintergrund hierfür ist auch die nicht ungeteilt positive, sondern durchaus 
kritische Stimmung der Entwickler selbst gegenüber der Umsetzung von Choreo 
in ihrer Abteilung. Diese Stimmung lässt sich in folgender Passage gut rekons- 
truieren: 


»Also man hat dieses Choreo ja gekannt aus der Produktion und hat dann, aus der Ent- 
wicklungssicht hat man gesehen, was verändert sich in der Produktion durch Choreo? 
Und dann hat jeder für sich das dann bewertet und hat dann festgestellt, mmh, das 
ist nicht so, worauf sich die Entwicklung freut [...]. Jetzt stellen Sie sich vor, Sie haben 
jemand, der hat studiert - wenn jemand studiert, dann hat der ein gewisses Maß an 
eigenständigem Arbeiten gelernt. Er hat auch den Nachweis erbracht, dass er was kann 
mehr oder weniger in der Naturwissenschaft, Maschinenbau oder so. Und jetzt kommt 
zu Ihnen jemand und der sagt Ihnen, wie viel Stifte Sie in der Schublade haben sollen, 
der sagt Ihnen, wo Sie Ihr Telefon hinzustellen haben, und der sagt Ihnen, wie Sie 
was zu machen haben. Das heißt also, man tut der Person gewisse Kompetenzen ab- 
sprechen, weil er sagt: Oh ja, Studium geschaft, vielleicht sogar promoviert und jetzt 
kommt da jemand und der sagt mir, wo ich mein Telefon hinzustellen habe, wie ich 
meine Schreibtischschublade aufzuräumen habe, der sagt mir, was ich zu machen habe. 
Also das ist eine Art Bevormundung, eine Gleichschaltung sozusagen, dass jeder mehr 
oder weniger austauschbar ist.« (A-5) 


Dieses Beispiel zeigt, dass bereits niederschwellige Maßnahmen wie die Neuge- 
staltung der Büroorganisation und das »gemeinsame Aufräumen« im Rahmen 
der typischen 5A-Workshops von den Beschäftigten mit wenig Begeisterung auf- 
genommen werden. Solche Maßnahmen werden weniger als eine partizipative 
Maßnahme erlebt, sondern vielmehr als ein illegitimer Eingriff in ihren per- 
sönlichen Arbeitsraum. Die Maßnahmen geraten hier in Widerspruch zu einer 
Expertenkultur, in der der einzelne Entwickler bis dato hohe Freiheitsgrade und 
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Autonomiespielräume hatte - gerade auch bei der Gestaltung seines individu- 
ellen Arbeitsplatzes. Zugespitzte Begriffe wie »Bevormundung« oder »Gleich- 
schaltung« machen deutlich, dass hier bisher gültige Anerkennungsordnungen 
verletzt werden. Die Maßnahmen werden als Standardisierung erlebt, in deren 
Folge die Individualität des Einzelnen ihre Berechtigung und Legitimität am 
Arbeitsplatz zu verlieren beginnt. Die Systematisierung und Optimierung der 
Büroorganisation wird zum Symbol für eine Arbeitswelt, in der »jeder mehr 
oder weniger austauschbar ist«. Der Befragte fährt schließlich fort, dass vor dem 
Hintergrund der »Aberkennung« der Spezialistenkultur »der Widerstand da in 
der Entwicklungsabteilung sehr groß war<.” 

Nach diesen ersten Lean-Ansätzen erreicht zum Erhebungszeitpunkt mit 
Choreo 2.0 eine zweite Lean-Welle die Entwicklung. Die nun vorangetriebenen 
Maßnahmen werden als substanziellere Veränderungen beschrieben, die auch 
die Arbeits- und Entwicklungsprozesse selbst betreffen. So wurde z.B. im Rah- 
men eines KVP-Projekts die Schnittstelle zur Produktion, die immer wieder 
situativ Entwicklungsleistungen nachfragt, funktionsbereichübergreifend neu 
gestaltet. Im Kern jedoch bedeutet in der untersuchten Abteilung Choreo 2.0 vor 
allem die Einführung von Shopfloor-Management und damit verbundenen re- 
gelmäßigen »Stehungen« des Teams am gemeinsam gepflegten Shopfloor-Board. 
Im Zentrum der »Stehung« steht ein kurzer Bericht jedes Teammitglieds über 
seinen Arbeitsfortschritt und seine aktuellen Aufgaben. Der Arbeitsstand wird 
dabei auf dem Board durch Kärtchen visualisiert. Darüber hinaus gibt es eine 
Spalte mit noch nicht bearbeiteten und zugewiesenen Aufgaben WArbeitsspei- 
cher«), aus der man sich ggf. Aufgaben »ziehen« kann. Zudem hat das Team 
mit dem Management Kennzahlen entwickelt. Eine wichtige Kennzahl ist bei- 
spielsweise, welchen Anteil der Arbeitszeit die Entwickler für ihre genuinen 
Entwicklungsprojekte aufwenden können und wieviel Ressourcen für andere 
Abteilungen - etwa für die Beantwortung von Anfragen oder kleinere Entwick- 


7 | Eine weitere Passage macht den nicht immer offenen, zuweilen subversiven Cha- 
rakter dieses »Widerstands« deutlich: »Natürlich, das hat in allen möglichen Formen 
zu Widerstand geführt, auf die kreativste Art und Weise. Dann sagt Ihnen jemand, 
ja, damit jeder weiß, dann machen wir dann ein Namenschild an Ihren Rollcontainer 
hin oder Büromaterial, was weiß ich, Blöcke oder so was, was halt in dieser Schub- 
lade drin ist. Ja, das führt dann halt zu dieser Kreativität [...] manche Leute haben ein 
Bild von ihrer Frau auf dem Schreibtisch, dann sehen wir halt dieses Bild beschriftet, 
»EHEFRAUg ja, oder dann in der Schublade haben sie dann ausgeschnitten, da steht 
dann drauf auf dem Schild: »APFEL«, dann setzen sie ihren Apfel sauber dort ein« 
(A-5). 
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lungsdienstleistungen - aufgewendet werden.’ Eine weitere wichtige Kennzahl 
ist das Verhältnis der »in time« erfolgreich erreichten Meilensteine zur Anzahl 
verschobener Meilensteine. 

Die Bedeutung und Wirkung des Shopfloor-Managements dürfen nicht unter- 
schätzt werden. Insbesondere für das Management werden so die Aktivitäten 
und der Arbeitsfortschritt der Entwicklung erheblich transparenter. Dazu tra- 
gen nicht nur die neuen Kennzahlen und deren kontinuierliche Pflege bei, 
sondern insbesondere das neue Format der Team»Stehung«. Schon durch die 
einfachen Methoden des Shopfloor-Boards - z.B. die Visualisierung von Arbeits- 
paketen mittels Karten und die Zuweisung zu einzelnen Entwicklern - werden 
die komplexen Abläufe in der vormaligen »Black Box« greifbar und klarer zu 
durchblicken. Durch den kontinuierlichen Charakter der »Stehungen« können 
Probleme und mögliche Abweichungen viel früher und nicht erst ex post er- 
kannt werden. Auch eine befragte Führungskraft argumentiert, dass diese »kurz- 
zyklische Steuerungsfähigkeit« deshalb ein »Kernanliegen« von Choreo 2.0 sei. 
Man wolle so die »Verlässlichkeit« steigern und erreichen, dass die »Entwicklung 
[...] ihre Projekte verlässlich durchzieht, dass sie zugesagte Termine hält« (A-4). 

Die neue Transparenz in der Arbeit hat auch Folgen für die Beschäftigten. 
Was sie in der Arbeit tun und auch was sie nicht tun, wird nun stärker als früher 
sichtbar. Sie verlieren - so eine befragte Führungskraft - ihre »Privatsphäre« in 
der Arbeit: 


»Und also für mich ist die Transparenz ganz klar ein Erfolg; und auch die Planung ver- 
bessern ist für mich auch ein Ziel. Weil bisher hat halt jeder auch seine Privatsphäre 
gehabt, hat das für sich geplant, das hat jeder anders gemacht. Der eine hat es in so 
ein Buch geschrieben, der andere hat sich im Outlook Merker gesetzt oder in irgend- 
welchen Excel-Tabellen Aufgabenverfolgung und so. Und jetzt ist es halt so, dass auch 
weniger Privatsphäre ist. Also man muss sich schon etwas öffnen und zeigen, was hat 
man alles getan. Man zeigt dann auch, wenn man Dinge nicht erledigt.« (A-4) 


Auch wenn gerade hinsichtlich des Erfahrungsaustauschs mit Kollegen und des 
Transfers von Wissen in den »Stehungen« positive Erfahrungen gemacht wur- 
den, gibt es auch von Seiten der Entwickler in der Folge kritische Stimmen. 
Bemängelt wird nicht nur der hohe zeitliche Aufwand für die »Stehungen«, son- 
dern insbesondere auch die Konsequenzen der damit verbundenen Transparenz 
in der Arbeit: 


»Und wir machen das ja bei uns am Montag, wo halt jeder Mitarbeiter sagt, was hat er 
letzte Woche gemacht und was möchte er kommende Woche machen. Und das wird 


8 | Dazu dokumentieren die Entwickler auch den individuellen Einsatz ihrer Arbeitszeit. 
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dann auch wieder unterschiedlich gesehen, sage ich mal. Auf der einen Seite ist das 
irgendwie eine komische Kontrolle und Rechtfertigung, weil man dann sagen muss, 
warum man das und das und das nicht gemacht hat. Also es wird zum Teil so auf- 
gefasst, dass es halt eine Art der Überwachung ist, und auf der anderen Seite [...] ist es 
ganz schwierig für denjenigen, der es berichtet, die richtige Flughöhe zu finden. Weil 
wenn der Kollege XY sagt, also er hat [...] für die Produktion Werte [...] gemessen, sagt 
er in der ersten Woche, das macht er in der zweiten Woche immer noch und in der 
dritten immer noch. Das interessiert, sage ich mal, den Chef, der weiß dann auch, wir 
unterstützen die Produktion wieder über Gebühr; den interessiert es, aber der Rest von 
der Abteilung, den interessiert das doch überhaupt nicht.« (A-5) 


Die in Begriffen wie »Überwachung«, »Rechtfertigung« oder auch »Kontrolle« 
zum Ausdruck kommenden Vorbehalte der Beschäftigten bleiben nicht ohne 
Wirkung in der Praxis. So wurde der Rhythmus der »Stehungen« stark einge- 
schränkt. Diese finden nun nicht mehr, wie ursprünglich vorgesehen, täglich 
statt, sondern nur noch einmal pro Woche. Ähnlich wie bei Choreo deutet sich 
an, dass auch der Nachfolger Choreo 2.0 von den Entwicklern nicht wirklich 
»gelebt« wird. Auf der einen Seite wird dabei deutlich, dass die Beschäftig- 
ten den in der Arbeitskultur verankerten Expertenmodus, der sie mit großen 
Freiheitsgraden und Primärmacht ausstattete, nicht einfach aufgeben wollen. 
Gerade die neue Transparenz wird hier zu einer Bedrohung der konstitutiven 
»Ungewissheitszonen« im Arbeitsprozess. Auf der anderen Seite wird jedoch 
auch konzeptioneller Handlungsbedarf deutlich. So spielt ein Empowerment der 
Mitarbeiter — als Antwort auf das Gefühl abnehmender Handlungsspielräume 
in einer wachsenden und mehr und mehr durch Prozesse getriebenen Organi- 
sation - keine zentrale Rolle. Interessanterweise bemängelt gerade eine befragte 
Führungskraft, dass »die Eigenverantwortlichkeit der Mitarbeiter zu stärken« 
(A-4) kein Kernanliegen von Lean im Unternehmen sei. 


Lean in den mittelqualifizierten Büro- und Servicebereichen 
Im Vergleich zum Bereich Forschung & Entwicklung ergibt sich in den mittel- 
qualifizierten Feldern der indirekten Bereiche im Unternehmen eine etwas an- 
dere Entwicklungsdynamik. Im Fokus steht hier der Technische Service. Auch 
hier bilden ein deutliches Wachstum der Abteilungen, steigende Arbeitsmengen 
und eine zunehmende organisatorische Ausdifferenzierung den betrieblichen 
Kontext für die Einführung und Umsetzung von Lean-Konzepten. In der Praxis 
zeigt sich jedoch, dass in diesen Bereichen Lean in Gestalt von Choreo und Cho- 
reo 2.0 mit größerer Konsequenz umgesetzt wird. 

Auffallend ist dabei zum einen, dass die Beschäftigten hier weniger Einfluss 
auf die konkrete Ausgestaltung des Programms und der damit verbundenen 
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Maßnahmen haben. Hintergrund hierfür ist nicht nur die geringere Primär- 
macht, sondern auch eine andere Arbeits- und Organisationskultur, die nicht 
so stark von der Figur des individuellen Experten geprägt ist. Zum anderen 
wurden auch die Kernarbeitsprozesse selbst zum Gegenstand von Veränderun- 
gen. Anders als in der Entwicklung ist man hier bereits bei der Umsetzung von 
Choreo nicht bei Fragen der Büroorganisation und bei SA-Workshops »stehen 
geblieben«, sondern hat Lean - z. B im Rahmen einer Vielzahl von KVP-Projek- 
ten - genutzt, um Prozesse zu optimieren und neu zu modellieren. Ziel war es 
dabei, die Abläufe professionell zu gestalten, Doppelarbeiten (insbesondere an 
den Schnittstellen zwischen verschiedenen Organisationsbereichen) zu vermei- 
den und so Efizienzgewinne zu erreichen. 

Nicht immer war bei der Neugestaltung und Restrukturierung von Prozes- 
sen Lean bzw. Choreo der unmittelbare Anlass oder Hebel. Oftmals ging es auch 
schlicht darum, Arbeitsprozesse an eine wachsende Organisation anzupassen 
oder auch neue IT-Lösungen zu nutzen. Entscheidend ist jedoch, dass die Kon- 
zepte von Lean für die Lösung der dabei auftretenden Fragen und Herausfor- 
derungen einen produktiven Bezugsrahmen darstellen. Als zentrale Konzepte, 
die hier zu nennen sind, gelten das Flussprinzip und das Denken in Prozessen, 
die ganzheitliche Betrachtung der Wertschöpfungskette über Abteilungsgren- 
zen hinweg, die Optimierung von Arbeitsschritten und die Vermeidung von 
Verschwendung ausgehend vom Kundennutzen, aber auch konkrete Tools wie 
etwa die Wertstromanalysen oder die Visualisierung von Prozessen. Gemäß der 
in Lean angelegten Idee der kontinuierlichen Verbesserung werden die Prozesse 
immer wieder neu hinterfragt, und ihre Optimierung bleibt permanent auf der 
Agenda. Die Ideen von Choreo und Choreo 2.0 erweisen sich praktisch als ein 
zentraler Impulsgeber für eine konsequente Prozessorientierung, für eine zu- 
nehmende Standardisierung, um Verschwendung zu vermeiden, sowie für eine 
fortschreitende systemische Integration der Organisation, in der Wertschöp- 
fungsprozesse über die Silostrukturen der Abteilungen hinweg permanent op- 
timiert werden. 

Die Grundlage für die konsequente Prozessorientierung bildet in der Pra- 
xis der hohe Grad der Informatisierung der Abläufe in den mittelqualifizierten 
Feldern der indirekten Bereiche. In den von uns untersuchten Bereichen sind 
Arbeitsgegenstand und Arbeitsmittel durchgängig digitalisiert. Beispielsweise 
werden alle Bestellungen und Transaktionen über ein IT-System abgewickelt 
und organisiert. Dabei werden verschiedene Abteilungen der eigenen Organisa- 
tion, aber auch eine Vielzahl externer Kunden und Lieferanten in einem System 
bruchlos miteinander vernetzt. Für die Mitarbeiter ist dieses System das zentra- 
le Arbeitsmittel. Der reale Fluss der benötigten Teile wird hier im Sinne einer 
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»strukturellen Dopplung« (Schmiede 1996) komplett informatorisch erfasst und 
organisiert. Folgerichtig kommentiert ein Sachbearbeiter: »Wir arbeiten hier nur 
mit Nummern« (A-7). Mit der zunehmenden Optimierung der Prozesse gelingt 
es hier, auch einen wachsenden Anteil der Transaktionen bzw. Bestellungen 
vollständig automatisiert abzuwickeln. Ziel ist es, die so frei werdenden Kapazi- 
täten der Mitarbeiter für höherwertige Tätigkeiten zu nutzen: von der bloßen 
Erfassung von Bestellungen hin zur Kundenberatung in komplexen Fällen, die 
(noch) nicht einem standardisierten Schema folgen. Gerade dieser hohe Grad an 
Informatisierung macht die Arbeit in den beschriebenen Bereichen einer kon- 
sequenten, von Flussprinzipien angeleiteten Prozessorientierung zugänglich. 
Digitale Informationen werden hier zum zentralen Arbeitsgegenstand und zum 
Gegenstand der Wertschöpfungsketten, die nun durchgängig und dem »flow of 
information« folgend gestaltet werden können. 

Neben einer konsequenten Prozessorientierung werden im Rahmen von 
Choreo in den untersuchten Bereichen schließlich auch Kennzahlen zur Steue- 
rung entwickelt und flächendeckend durchgesetzt. Diese dienen insbesonde- 
re dazu, die Entwicklung der Produktivität zu messen und ggf. Defizite und 
Schwierigkeiten transparent zu machen. In den untersuchten Bereichen sind 
wichtige Kennzahlen z.B. der tägliche Umsatz der Abteilung, die Anzahl der 
Aufträge pro Mitarbeiter oder auch die telefonische Erreichbarkeit. Zudem wird 
täglich erfasst, ob am Ende eines Tages Aufträge nicht vollständig bearbeitet 
liegen bleiben - Ziel ist es hier, täglich den Auftragsvorrat komplett und voll- 
ständig bearbeitet zu haben. Auch wenn diese Kennzahlen durchaus akzeptiert 
werden und zu einem alltäglichen Bestandteil der Arbeitskultur geworden sind, 
begegnen die Mitarbeiter ihnen mit einer gewissen Skepsis. Kern der Kritik - 
die auch eine befragte Führungskraft teilt - ist, dass diese Kennzahlen letztlich 
oberflächlich bleiben und nichts über den qualitativen Charakter der Arbeit aus- 
sagen. Zum Beispiel gibt die bloße Anzahl der bearbeiteten Bestellungen kei- 
ne Information über deren Komplexität und den wirklich damit verbundenen 
Arbeitsaufwand.” Aus der Perspektive der Beschäftigten dienen die Kennzahlen 


9 | So argumentiert exemplarisch ein Sachbearbeiter: »Also wir diskutieren so im Kol- 
legenkreis oft über den Sinn oder die Richtigkeit der Kennzahl. Weil jetzt z.B. in die 
Produktivität wird nur die Fallzahl, also der Bestelleingang eingerechnet. Aber ich 
habe ja auch noch ein E-Mail-Postfach, was meistens viel, viel mehr Zeit benötigt wie 
jetzt die eigentliche Auftragsabwicklung oder den Auftrag anlegen. Und deshalb müss- 
te man ja eigentlich sagen, dass quasi die Anzahl der E-Mails pro Tag noch, also noch 
dazu gerechnet wird. Wird aber zumindest bis jetzt noch nicht gemacht.« (A-7) Ein Be- 
schäftigter aus dem Service-Bereich argumentiert ähnlich: »Deswegen ist es im Service 
immer so, ja so ein bisschen nicht ein Widerstand, wir machen ja keinen Widerstand, 
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daher insbesondere dem Management in seinem Bestreben, mehr Transparenz 
zu gewinnen. Bislang hat in diesem Bereich auch das obere Management die 
zu erhebenden Kennzahlen vorgegeben. Zum Erhebungszeitpunkt wird jedoch 
im untersuchten Bereich angestrebt, im Rahmen von Choreo 2.0 nicht nur nach 
verbesserten Prozessen zu suchen, sondern auch danach zu fragen, welche Kenn- 
zahlen die qualitativen Aspekte der geleisteten Arbeit (z.B. die Komplexität der 
bewältigten Aufgaben) besser erfassen könnten. 

Besonders interessant ist, dass die ermittelten Kennzahlen keineswegs nur 
für das Management ermittelt werden, sondern gezielt in die täglichen Arbeits- 
routinen der Beschäftigten eingebunden werden. Dazu dient insbesondere 
das tägliche Team-Meeting am Shopfloor-Board. Dieses wird wesentlich konse- 
quenter umgesetzt als etwa in der Forschung & Entwicklung." Es findet nicht 
nur täglich statt (als Beginn des Arbeitstages), sondern folgt auch einem klar 
strukturierten Ablauf. Erster Tagesordnungspunkt ist dabei die tägliche Vor- 
stellung und Aktualisierung der wichtigsten Kennzahlen des Teams. Dem folgt 
ein kurzer Bericht der Teamleitung über aktuelle Veränderungen und Projekte. 
Anschließend können sich die Mitarbeiter austauschen und sich z.B. bei Fragen 
oder Problemen Rat und Anregungen aus dem Team holen. Die entsprechenden 
Ergebnisse werden in der Praxis dann - konsequent dem Konzept des Shopfloor- 
Managements folgend - nach oben kaskadiert. So folgt dem Team-Meeting das 
Shopfloor-Meeting der Teamleiter. 

Das Shopfloor--Management schafft in der Praxis nicht nur - wie oben für 
den Bereich der Forschung & Entwicklung gezeigt - mehr Transparenz in den 
Arbeitsprozessen, sondern kann auch die Arbeitsweise im Team und die So- 
zialintegration der Teams selbst verändern. In den untersuchten Bereichen, in 
denen auf eine konsequente Umsetzung gedrungen wird, deutet sich an, dass die 
Ebene des Teams im Arbeitsalltag an Bedeutung gewinnt. Auf der einen Seite 
entsteht mit den täglichen Meetings ein neuer Raum, der für Wissensaustausch 
und fachliche Unterstützung zwischen den Mitarbeitern genutzt wird. Auf der 
anderen Seite eröffnen die täglichen »Stehungen« auch neue Möglichkeiten für 
die Selbstorganisation im Team. In der Praxis zeigt sich jedoch, dass diese quali- 


aber halt so ein unter Vorbehalt mit dem Choreo alles so in Zahlen zu fassen. Weil das 
kann man in einer Produktion sagen, wo wirklich Zahlen getaktet sind oder wo man 
weiß, ich brauche halt so und so lang für irgendwas. Aber bei uns ist das halt einfach 
nicht so. Und deswegen mit jetzt Zahlen von Produktivität oder irgendwie sich das von 
oben anzuschauen, ist schwierig.« (A-9) 

10 | Der untersuchte Bereich gilt als einer der Vorreiter für die Umsetzung von Cho- 
reo 2.0 in den indirekten Bereichen des Unternehmens. 
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tativ derzeit nicht das Niveau wie etwa in klassischen Scrum-Teams erreicht. Im 
Vordergrund steht hier zunächst vor allem die situative Kapazitätsplanung und 
die Organisation der individuellen Arbeitsmenge - z.B. bei Belastungsspitzen 
oder auch bei krankheitsbedingtem Ausfall von Kollegen.” 

Besonders interessant ist schließlich, dass über die täglichen »Stehungen« im 
Team die täglich aktualisierten Kennzahlen in der Arbeitspraxis und auch in der 
sozialen Welt des Teams an Bedeutung gewinnen. Ein Mitarbeiter beschreibt 
dies sehr anschaulich: 


»Vielleicht auch so ein bisschen dieses Wir-Gefühl - ist jetzt vielleicht falsch; aber ein- 
fach, dass man sagt >Hey, wir hatten gestern wieder so einen Berg zu tun« - übrigens, 
ich habe noch eine Kennzahl vergessen, »Platte blank« heißt die. Also keine Aufträge, 
die wirklich heute rausmussten, sind liegen geblieben. [...] Und eben dann z.B. dass 
man sich sozusagen fast ein bisschen auf die Schulter klopft und sagt »Hey, wir hatten 
gestern 400 Fälle und es ist alles rausgegangen« [...]. Oder auch dann, wenn man über 
zwei Wochen lang sieht »Hey, wir sind immer Umsatz über Ziel, einfach auch so ein 
bisschen »Hey, wir sind auf einem guten Weg«. Dafür ist es dann eigentlich ja wieder 
wichtig und wenn es auch bloß eigentlich eine blöde Information ist.« (A-7) 


Diese Passage führt vor Augen, dass der regelmäßige Diskurs und die gemeinsa- 
me Reflexion der Kennzahlen im Team nicht folgenlos bleiben. Die Kennzahlen 
werden zu einer relevanten Bezugsgröße im Arbeitsalltag der Teams und tragen 
zur Integration des Teams merklich bei - der Befragte spricht, wenn auch zöger- 
lich, von einem »Wir-Gefühl«. Auch aus steuerungs- und kontrolltheoretischer 
Perspektive ist diese Passage sehr interessant. Offensichtlich hilft der gemeinsa- 
me Diskurs im Team, die Mitglieder dazu zu motivieren, auf ein gemeinsames 
Ziel hinzuarbeiten. Die Ebene der »Öffentlichkeit« wird hier genutzt, die soziale 
Anerkennung der Kennzahlen zu stärken und als gemeinsam getragene legitime 
Steuerungsgröße zu verankern. 

Auch wenn man die konkrete Wirkung nicht überbewerten sollte, zeigen sich 
hier exemplarisch das grundsätzliche Potenzial und die Wirkungsweise neuer 


11 | Dies beschreibt ein Mitarbeiter folgendermaßen: »Angenommen also, wir haben 
jetzt die Situation, ein Kollege ist krank oder also eben kurzfristig ungeplant dann, und 
ich hätte jetzt eben dadurch noch zwei Länder dazubekommen. Und ich sche einfach 
schon morgens, das wird knapp eben gerade noch mit den Deadlines, z.B. bis um 10 
Uhr, dass ich einfach für mich sage: »Das wird wahrscheinlich nicht reichen, dass ich 
das alles hinkriege«, dann wird auch die Stehung genutzt, um das einfach zu sagen. [...] 
dass dann eben jemand sagt: »>Okay, komm, bei mir geht es, ich mache das und das oder 
ich helfe dir da einfach geschwind.« Und dafür wird es auf jeden Fall genutzt, ist auch 
wichtig.« (A-7) 
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Methoden wie Shopfloor-Management. Über die kontinuierliche Erfassung und 
Reflexion von Kennzahlen, die Schaffung von Transparenz in der Arbeit durch 
die Teammitglieder selbst, die Stärkung der Teamebene (bis hin zu Formen der 
Selbstorganisation) und die kontinuierliche Schaffung einer »Teamöffentlichkeit« 
entstehen neue Möglichkeiten zum Management und zur Steuerung der Arbeit 
in den indirekten Bereichen. 


3.1.4 Zusammenfassung 


Mit der Umsetzung neuer Lean-Methoden in den indirekten Bereichen hat das 
Fallunternehmen bereits seit vielen Jahren Erfahrungen sammeln können. Ins- 
besondere nachdem mit der Einführung von Lean in der Fertigung die Produk- 
tivität sprunghaft gesteigert werden konnte, hat man früh damit begonnen, 
Lean und die damit verbundenen Konzepte auch in die indirekten Bereiche zu 
übertragen. In der Produktion war insbesondere die Einführung der Fließferti- 
gung der Angelpunkt der rasant gestiegenen Produktivität. Die Einführung von 
Lean in den indirekten Bereichen war zunächst nicht durch einen vergleichbar 
grundlegenden und unmittelbaren »Hebel« gekennzeichnet. Ähnlich wie in an- 
deren Unternehmen setzte man deshalb auf inkrementelle Optimierungen und 
Verbesserungen, die auf zentrale Lean-Methodiken zurückgriffen. Das stufen- 
förmig aufgebaute Programm reichte dabei von 5A-Workshops über die Opti- 
mierung von Prozessen und Schnittstellen bis hin zur Einführung von Kenn- 
zahlen. Der konzeptionelle Fokus lag auf der Vermeidung von Verschwendung 
und auf dem Kontinuierlichen Verbesserungsprozess. 

Mit der Einführung von Choreo 2.0 wird nun jedoch eine neue Phase ein- 
geleitet. In der Praxis wird diese neue bzw. weiterentwickelte Lean-Initiative vor 
allem als die flächendeckende Einführung von Shopfloor-Management erlebt. 
Auch in den indirekten Bereichen wird diese neue Methode nun konsequent 
eingeführt - die überall im Unternehmen sichtbaren Shopfloor-Tafeln machen 
die Umsetzung von Lean nun auch im Büro greifbar und konkret. Die tägli- 
chen Team-»Stehungen« am Board, die Visualisierung von Arbeitspaketen und 
Bearbeitungsstatus und die kontinuierliche Pflege zentraler Kennzahlen führen 
gerade in den indirekten Bereichen zu einer neuen Transparenz in der Arbeit. 
Im Hinblick auf die Umsetzung ist hier der Vergleich von Forschung & Ent- 
wicklung mit den mittelqualifizierten Service- und Verwaltungsabteilungen 
instruktiv: Während in letzteren Bereichen eine sehr konsequente Umsetzung 
zu erkennen ist, verläuft die Einführung in den hochqualifizierten Bereichen 
relativ gebremst. Die Beschäftigten gerade in den hochqualifizierten Bereichen 
wollen ihre mit den Ungewissheitszonen im Arbeitsprozess verbundenen Pri- 
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märmachtpotenziale kaum aufgeben und den individualistisch geprägten Ex- 
pertenmodus weiter leben. 

Der Vergleich der beiden Bereiche ist auch aus anderer Perspektive instruk- 
tiv. Gerade in den mittelqualifizierten Feldern der indirekten Bereiche ist im 
Unternehmen eine zunehmende Prozessorientierung zu erkennen. Hintergrund 
hierfür ist die fortschreitende Informatisierung der Arbeit und ihre konsequente 
Überführung in umfassende IT-Systeme. Der bruchlose »flow of information« 
öffnet diese Arbeitsbereiche zentralen Gestaltungskonzepten von Lean wie dem 
Flussprinzip. In der Praxis werden die Informatisierung der Prozesse und Lean 
jedoch bislang kaum systematisch aufeinander bezogen und verknüpft. Hierin 
könnten für das Unternehmen in der Zukunft mit Blick auf die Anwendung 
von Lean in den indirekten Bereichen grundlegende Potenziale bestehen - der 
Hebel, der in der Produktion die Fließfertigung war, könnte für die indirekten 
Bereiche die konsequente Verknüpfung von Informatisierung und Lean werden. 
Statt eines alleinigen Fokus auf »Vermeidung von Verschwendung« könnte dann 
die »systemisch integrierte Organisation« zum konzeptionellen Ausgangspunkt 
werden. 


3.2 Fallstudie B: Rollout von Lean in den indirekten Bereichen 


3.2.1 Unternehmenscharakteristik und Ausgangsbedingungen 


Das Fallunternehmen ist ein Konzern aus der Metall- und Elektroindustrie. Zum 
Erhebungszeitpunkt beschäftigt er weltweit mehrere 100.000 Mitarbeiter, davon 
mehr als die Hälfte in Deutschland. Nicht nur die Konzernzentrale, sondern 
auch maßgebliche Produktionsstandorte und ein großer Anteil der Entwick- 
lung befinden sich weiterhin in Deutschland. Die indirekten Bereiche jenseits 
der Fertigung haben auch in diesem Industrieunternehmen deutlich an Be- 
deutung gewonnen. So machen sie heute am untersuchten Standort bereits die 
Hälfte der Beschäftigten aus, in Deutschland liegt der Anteil sogar etwas über 
50 Prozent. Hintergrund für die Verschiebung des Verhältnisses zwischen Wer- 
kern und indirekten Bereichen sind nicht zuletzt die Rationalisierungsgewinne 
in der Produktion. Nachdem hier zunächst Nachteile gegenüber Wettbewerbern 
identifiziert worden waren, konnten seit den 1990er Jahren insbesondere durch 
die Einführung von »Ganzheitlichen Produktionssystemen« große Eflizienzstei- 
gerungen erzielt werden. Auch bei der Übertragung von Lean in die indirekten 
Bereiche gilt das Unternehmen als Vorreiter und treibt dieses Projekt aktiv und 
stetig voran. 


67 


Kapitel 3 


Nachdem bei der Rationalisierung der Produktion große Fortschritte er- 
zielt worden sind, rücken nun vermehrt die indirekten Bereiche in den Fokus. 
Dabei sind die Veränderungen in den Bereichen Verwaltung und Entwicklung 
hinsichtlich der Schwerpunktsetzungen und Geschwindigkeiten zu unterschei- 
den. So wurde bereits Mitte der 2000er Jahre begonnen, mit groß angelegten 
konzernweiten Initiativen Kosten in der Verwaltung einzusparen und Personal 
abzubauen. Dabei wurden auch die Arbeitsprozesse selbst grundlegend verän- 
dert und zentrale Verwaltungsfunktionen in Shared Services zusammengeführt. 
Demgegenüber verlaufen die Reorganisations- und Rationalisierungsprozesse in 
der Entwicklung weniger konsequent und folgenreich. Insbesondere in den Ver- 
waltungsbereichen hat der Abbau von Personal schließlich zu einer spürbaren 
Verdichtung der Arbeit geführt. Um die Aufgaben mit den reduzierten Perso- 
nalkapazitäten bewältigen zu können und weiteres Wachstum zu ermöglichen, 
waren deshalb neue Anstrengungen notwendig, um Prozesse zu optimieren und 
die Produktivität zu steigern. 

Vor diesem Hintergrund hat Lean auch in den indirekten Bereichen eine 
strategische Bedeutung gewonnen. Anders als beispielsweise in Fallunterneh- 
men F wird Lean hier nicht dezentral und nach dem Prinzip der »Freiwilligkeit« 
in einzelnen Abteilungen eingesetzt, sondern die Umsetzung erfolgt flächende- 
ckend. Ausgehend von einem Vorreiter-Bereich, dem Personalbereich, wird Lean 
sukzessive in den Verwaltungsbereichen und der Entwicklung ausgerollt. Zen- 
trale Ziele der Lean-Einführung sind dabei die Implementierung eines Konti- 
nuierlichen Verbesserungsprozesses und die Beseitigung von »Verschwendung«. 
Damit sollen Rationalisierungseffekte in der Verwaltung erreicht werden, damit 
die Verdichtung von Arbeit bewältigt werden kann und intern neue Personalres- 
sourcen für wachsende Aufgabenbereiche gewonnen werden können. Auf Basis 
einer Gesamtbetriebsvereinbarung wird die Einführung von Lean vom Betriebs- 
rat aktiv begleitet und gestaltet. 


3.2.2 Umbruch im Büro: 
Shared Services und der Wandel in den indirekten Bereichen 


Den strategischen Hintergrund für die breite Umsetzung von Lean in den in- 
direkten Bereichen bildet eine langjährige Abfolge von Reorganisations- und 
Rationalisierungsmaßnahmen in den indirekten Bereichen. Nachdem histo- 
risch die Angestelltenbereiche lange von Sparmaßnahmen verschont geblie- 
ben waren, sind sie seit Ende der 1990er Jahre verstärkt in den strategischen 
Fokus von Konsolidierungs- und Kostensenkungsprogrammen geraten, wozu 
auch die Verlagerung von Arbeitsplätzen in Niedriglohnregionen gehörte. Da- 
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bei verlief der Prozess in Verwaltung und Forschung & Entwicklung unter- 
schiedlich. 


Der Wandel der Verwaltungsbereiche 

In der Abfolge der seit den 1990er Jahren aufgelegten Programme kam es Mitte 
der 2000er Jahre zu einer qualitativen Zäsur, als ein konzernweites Rationali- 
sierungs- und Kostensenkungsprogramm beschlossen wurde, im Zuge dessen 
die Verwaltungsbereiche reorganisiert werden sollten. Während es in vorheri- 
gen Programmen nur um Kostensenkung gegangen war, handelte es sich hier 
nun um die erste strategische Initiative zur Neuorganisation der Arbeitsprozesse 
in der Verwaltung. Hauptziele waren eine verstärkte Zentralisierung, die Ver- 
schlankung von Prozessen und die Reduktion von Komplexität. 

Das grundlegende Element der Reorganisation war die Anwendung von 
Shared-Services-Konzepten, durch die Verwaltungsfunktionen wie z.B. das Rech- 
nungs- und Personalwesen effizienter gestaltet werden sollten. Diese Aufgaben 
waren bislang an den einzelnen Standorten dezentral erledigt worden und zeich- 
neten sich durch historisch gewachsene heterogene Strukturen und Abläufe aus. 
Oftmals hatten sich an unterschiedlichen Standorten für gleiche Vorgänge und 
Aufgaben sehr unterschiedliche Routinen und Verfahren herausgebildet. Durch 
die Etablierung von Shared Services sollte vor allem eine Zentralisierung bzw. 
Konsolidierung dieser Funktionen an wenigen Standorten erreicht und gleich- 
zeitig die Prozesse standardisiert und vereinheitlicht werden. Die Grundlage der 
damit verbundenen Prozessorientierung war die Nutzung einheitlicher IT-Syste- 
me. Insgesamt sollten so durch effektive, IT-gestützte Prozesse und die Erschlie- 
Bung von Economies of Scale die Kosten deutlich gesenkt werden. 

Bei der Umsetzung des Shared-Services-Konzepts lassen sich im Rückblick 
mehrere Wellen erkennen. Der Fokus der ersten Welle lag zunächst auf einer 
grundlegenden Orientierung der Verwaltung in Richtung Shared Services sowie 
auf der Senkung von Kosten. Insgesamt sollten mit dem entsprechenden Rah- 
menprogramm mehrere Milliarden Euro u.a. dadurch eingespart werden, dass 
das Personal in den Zentralbereichen innerhalb von drei Jahren um 20 Prozent 
reduziert werden sollte. Allein in Deutschland bedeutete dies einen Personal- 
abbau von mehreren Tausend Beschäftigten. 

Die Aufmerksamkeit richtete sich dabei insbesondere auf transaktionale Fel- 
der im Bereich des Rechnungs- und Personalwesens. Um die Einsparziele zu er- 
reichen, wurde jedoch nicht nur auf eine Vereinheitlichung der Prozesse gesetzt, 
sondern auch eine Verlagerung einzelner Tätigkeitsfelder in Niedriglohnländer 
geplant, etwa nach Asien oder Osteuropa. Dies führte zu starken betrieblichen 
Auseinandersetzungen, wobei sich auch die Angestellten an Protesten gegen 
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mögliche Verlagerungen beteiligten. In einem Kompromiss mit dem Betriebs- 
rat wurde schließlich beschlossen, auf Verlagerungen ins Ausland zu verzichten 
und stattdessen neue Shared-Services-Standorte in Ostdeutschland aufzubauen. 
Zudem wurde ein Verzicht auf betriebsbedingte Kündigungen und Änderungs- 
kündigungen im Zuge der Verwaltungsrestrukturierung mit einer Laufzeit von 
zwei Jahren vereinbart. 

Zum Erhebungszeitpunkt befindet sich das Unternehmen in einer zweiten 
Welle der Umsetzung des Shared-Services-Konzepts. In dieser Phase sollen weite- 
re Funktionen verlagert und das Konzept auf weitere Tätigkeiten und Bereiche 
angewendet werden. Während in der ersten Phase der Fokus auf vergleichsweise 
leicht standardisierbaren Tätigkeiten lag, werden jetzt auch komplexere Tätig- 
keitsbereiche - etwa das Controlling - in den Blick genommen. Auf Basis einer 
Funktionsanalyse wurden im Controlling bereits Tätigkeiten und Stellen identi- 
fiziert, die ausgelagert werden können. Eine Betriebsrätin formuliert: »Man ist 
jetzt die Wertschöpfungskette hochgekrabbelt.« 


Der Wandel der Forschungs- und Entwicklungsbereiche 

Der Wandel der Forschungs- und Entwicklungsbereiche vollzieht sich im Ver- 
gleich dazu wesentlich langsamer; auch nimmt er einen anderen Verlauf, was 
verständlich wird, wenn man die Ausgangslage und die Besonderheiten dieser 
Bereiche in den Blick nimmt. Die Entwicklung, in der hochqualifizierte Inge- 
nieure arbeiten, gilt als »Herzstück« des Unternehmens. Die Kernentwicklung - 
und damit ein sehr großer Anteil der Entwicklungsmannschaft - ist bis heute 
in Deutschland angesiedelt. Nur 20 Prozent der Mitarbeiter in der Forschung & 
Entwicklung sind zum Erhebungszeitpunkt im Ausland beschäftigt. Auch der 
Wandel der Arbeit selbst vollzieht sich im Vergleich zur Verwaltung mit deut- 
lich geringerer Geschwindigkeit. Während dort mit den Shared Services ein qua- 
litativer Bruch in der Arbeitsorganisation vollzogen wurde, verlaufen hier die 
Standardisierung der Arbeit und die Durchsetzung einer stärkeren Prozessorien- 
tierung schleichend und inkrementell. 

Dennoch beginnen sich im Fallunternehmen auch in der Arbeit der Ent- 
wickler grundlegende Koordinaten zu verschieben. Ein entscheidender Faktor 
ist dabei, dass ein wachsender Teil von Entwicklungsaufgaben an kostengüns- 
tige Engineering-Dienstleister ausgelagert wird. Alles, was nicht zu den un- 
mittelbaren Kernkompetenzen der Entwicklung gehört, wird Gegenstand von 
Outsourcing-Bemühungen. Teil dieser Strategie ist auch, Entwicklungsaufgaben 
nicht mehr eigenen Beschäftigten zu übertragen, sondern einer wachsenden 
Zahl von Werkauftragnehmern. Das hat selbstredend Konsequenzen für die 
Arbeit der Entwickler selbst. In unseren Interviews berichten sie, dass immer 
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weniger Zeit für die eigentliche Entwicklung bleibe. Stattdessen sei der Arbeits- 
tag immer mehr davon geprägt, dass sie die Beiträge von Werkauftragnehmern 
und Engineering-Dienstleistern im Sinne eines Projektleiters steuern und ko- 
ordinieren. Dementsprechend gingen ihnen Spielräume verloren, eigenständig 
zu entwickeln. 

Darüber hinaus gewinnt allmählich auch die Globalisierung in der For- 
schung & Entwicklung an Bedeutung. Während man sich lange darauf be- 
schränkt hatte, lediglich in Schlüsselmärkten und an wichtigen Technologie- 
standorten kleine Niederlassungen aufzubauen, die im Sinne von »Horchposten« 
zentrale technologische Trends aufgreifen und transferieren sollten, erfolgte in 
den letzten Jahren hinsichtlich der Internationalisierung der Forschungs- & Ent- 
wicklungsbereiche ein Entwicklungsschub. Insbesondere in Asien wurden gro- 
ße Entwicklungszentren eingerichtet, denen das Management große Bedeutung 
für die Zukunftsstrategie des Konzerns beimisst und die es in den nächsten Jah- 
ren ausbauen möchte. Folgt man unseren Gesprächspartnern, fürchten die Be- 
schäftigten am untersuchten Standort Know-how-Verluste und eine Gefährdung 
der fokalen Position der bisherigen Zentralstandorte im sich neu konturieren- 
den Entwicklungsnetzwerk des Unternehmens. Für viele Beschäftigte auch in 
Bereichen der Forschung & Entwicklung haben Kostendruck, Rationalisierung 
und die Bedrohung durch Personalabbau eine neue Qualität gewonnen. 


3.2.3 Lean im Büro in der Praxis 


Nachdem die Rationalisierungs- und Kostensenkungsprogramme weitreichen- 
de Einsparungen erreicht hatten, blieb jedoch die Frage aktuell, wie die Prozesse 
effizienter und produktiver gestaltet werden können. Der Abbau von Personal 
hatte zu einer deutlichen Arbeitsverdichtung und steigenden Belastungen bei 
den verbliebenen Beschäftigten geführt, aber die Qualität und Stabilität der Pro- 
zesse hatten unter dem Abbau auch gelitten. Die Suche nach weiteren Produk- 
tivitätspotenzialen führte das Fallunternehmen schließlich zu der Frage, ob die 
Erfolge der Ganzheitlichen Produktionssysteme in der Fertigung auch auf die 
indirekten Bereiche übertragen werden können. Deshalb wurde vom Vorstand 
unter der Überschrift »Kontinuierliche Verbesserung« Lean auch dort vorange- 
trieben. Zentrale Maßgabe war nun, die Produktivität deutlich zu steigern, um 
das Leistungsspektrum mit dem reduzierten Personal weiterhin stabil erbringen 
zu können. '? 


12 | Dieser spezifische strategische Zugang des Unternehmens bei Einführung von 
Lean ist durchaus bemerkenswert. Während andere Unternehmen versuchen, Lean als 
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Dadurch nimmt Lean aktuell einen zentralen Stellenwert im Unternehmen 
ein und bildet das orientierende Konzept, mit dem die Arbeitsprozesse sowohl 
in der Verwaltung als auch in der Entwicklung optimiert werden. Während in 
der Phase zuvor vor allem die Kostensenkung in der Verwaltung durch die Grün- 
dung von Shared Services und Personalabbau im Vordergrund stand, geht es mit 
Lean jetzt um die Optimierung der Arbeitsorganisation. Es wird gezielt auf das 
Wissen der Beschäftigten selbst zugegriffen, um einen kontinuierlichen Verbes- 
serungsprozess voranzutreiben. 

Charakteristisch für das Fallunternehmen ist dabei die Konsequenz, mit der 
die Lean-Einführung vorangetrieben wird. Nachdem zunächst mit einigen »un- 
kritischen« Pilotprojekten begonnen worden war, wird Lean zum Erhebungs- 
zeitpunkt sukzessive nach einem festgelegten Plan sowohl in der Verwaltung 
als auch in der Forschung & Entwicklung sehr konsequent ausgerollt. Die Ein- 
führung von Lean erfolgt in der Regel »top down« und wird sowohl von der in- 
ternen Lean-Abteilung als auch von den einschlägigen Beratungsunternehmen 
begleitet. Parallel dazu wird versucht, die Einführung von Lean »bottom-up« 
zu verankern, indem Beschäftigte zu Multiplikatoren ausgebildet werden. Diese 
begleiten für einige Monate die Lean-Implementierung in einer anderen Abtei- 
lung, um im Anschluss die Einführung in der eigenen Abteilung aktiv zu unter- 
stützen. 

Die Einführung lässt sich idealtypisch als dreischrittiger Prozess beschrei- 
ben: Im ersten Schritt werden in ausgewählten Bereichen kleine Lean-Projek- 
te durchgeführt, um den Beschäftigten Lean nahezubringen und eine Kultur 
der »kontinuierlichen Verbesserung« zu initiieren. In Workshops identifizieren 
Mitarbeiter Optimierungspotenziale und setzen diese danach in Maßnahmen 
um. Ein typisches Beispiel hierfür sind gemeinsame Aufräumarbeiten (SA-Work- 
shops). Ziel ist, dass die Beschäftigten Lean als etwas Positives erleben. So dient 
diese Phase als »Türöffner« für die weiteren Schritte. Im folgenden Schritt wird 
Shopfloor-Management flächendeckend eingeführt. Dadurch wird eine neue Qua- 
lität von Transparenz über die Aufgaben des Teams geschaffen, und es entsteht 
eine Grundlage für die Steuerung des Teams. Im dritten Schritt werden größere 
Projekte in Gestalt von Wertstromanalysen durchgeführt, die sich über mehrere 
Monate erstrecken und auf die Entwicklung von Standards und Prozessopti- 
mierung fokussieren. Sie umfassen sowohl Tätigkeitsstrukturanalysen als auch 
abteilungsübergreifende Prozessanalysen. 


Instrument für Personalabbau einzuführen (und damit häufig auf den Widerstand der 
Beschäftigten stoßen), wurde hier erst Personal abgebaut und danach Lean als Antwort 
auf die massive Arbeitsverdichtung eingesetzt. 
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Auch wenn die Einführung von Lean in den unterschiedlichen Bereichen 
auf demselben Methodenrepertoire basiert, unterscheidet sich die Einsatzweise 
der Methoden zwischen Bereichen und Abteilungen, und der Prozess ist unter- 
schiedlich weit fortgeschritten. Um dieser Differenziertheit gerecht zu werden, 
wird im Folgenden je ein Fallbeispiel aus der Verwaltung und aus der Entwick- 
lung in den Blick genommen. Dabei interessiert uns sowohl die konkrete Aus- 
gestaltung von Lean in der Praxis als auch die Sicht der Beschäftigten. 


3.2.3.1 Fallbeispiel I: Lean in einer Controlling-Abteilung 

Die untersuchte Abteilung beschäftigt um die 50 Personen, die in fünf Teams 
aufgeteilt sind. Sie wurde erst vor wenigen Jahren im Rahmen der Shared-Services- 
Initiativen und der Zentralisierung von Tätigkeiten am Standort aufgebaut. Lean 
wurde hier in Zusammenarbeit mit der internen Lean-Abteilung eingeführt. 
Das Ziel der Einführung ist die Erzielung von 15 Prozent Rationalisierungs- 
effekten innerhalb eines Jahres. Dies bedeutet konkret, dass 15 Prozent »freie 
Kapazität« gewonnen werden sollen, die entweder abgebaut oder mit neuen Auf- 
gaben gefüllt werden sollen. 

Das untersuchte Team befasst sich mit Datensätzen aus einem IT-System, 
die ausgewertet und in Berichten zusammengefasst werden. In der Arbeitspraxis 
sind zwei Arten von Aufgaben zu unterscheiden: Es gibt sog. Standard-Aufga- 
ben - typische Auswertungen eines Datensatzes -, die jeder im Team bearbei- 
ten kann, und Spezialauswertungen, die nur bestimmte Experten übernehmen 
können, von denen es häufig nur einen pro Team gibt. Die Aufgaben des Teams 
sind vergleichsweise kleinteilig und dauern normalerweise zwischen einer hal- 
ben Stunde und drei Stunden. Sie werden in der Regel von den einzelnen An- 
gestellten übernommen und erfordern keine Teamarbeit. Zwei Arten von Auf- 
gaben strukturieren zeitlich die Arbeit des Teams: lange im Voraus planbare 
und kurzfristige, ungeplante Aufgaben. Erstere umfassen die Erstellung monat- 
licher Berichte und die Vorbereitung von Berichten für dreimal jährlich statt- 
findende Planungsrunden. Diese Termine sind schon lange im Voraus bekannt. 
Demgegenüber handelt es sich bei den ungeplanten Aufgaben um kurzfristige 
Anfragen anderer Abteilungen, die eine schnelle Bearbeitung erfordern und in- 
nerhalb von 48 Stunden erledigt sein müssen. 

Gemeinsam mit der internen Beratungsabteilung wurde Lean im Team ein- 
geführt, beginnend mit einer mehrwöchigen Einführungsphase, in der das Team 
in kleinen Projekten zunächst mit Lean vertraut gemacht wurde. Die Hauptphase 
der Einführung umfasst hier drei zentrale Elemente: die Einführung von Shop- 
floor-Management, die Standardisierung von Aufgaben sowie die Prozessoptimie- 
rung und die Initiierung eines kontinuierlichen Verbesserungsprozesses. 
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Das Shopfloor-Management 

Das Shopfloor-Management ist das Kernelement der Lean-Einführung. Dabei 
wird ein Shopfloor-Board zur Abbildung der Tagesplanung der einzelnen Mit- 
arbeiter genutzt. Auf dem Board ist ersichtlich, woran jeder Mitarbeiter an 
einem bestimmten Tag arbeitet und wie viel Zeit dafür veranschlagt ist. Um die 
Aufgaben für die Woche nicht aus dem Blick zu verlieren, ist zusätzlich ein sog. 
»Parkplatz« für absehbar anfallende Aufgaben vorhanden. Zentraler Fokus des 
Shopfloor-Managements ist in diesem Team die Tagesplanung. Dazu trifft sich das 
Team jeden Morgen vor dem Board zum sog. »Check-in« und bespricht den Tag. 
Jeder Mitarbeiter stellt hierfür seine für den Tag geplanten Aufgaben vor und 
schätzt, wie lange er für ihre Erledigung benötigt. Da die Aufgaben schr klein- 
teilig sind, können sie in der Regel jeweils an einem Tag fertiggestellt werden. 
Eine der Interviewpersonen beschreibt diesen Prozess anschaulich in folgender 
Passage: 


»Lean machen wir jeden Morgen eine Viertelstunde, das ist so eine Tafel wie die hier, 
ungefähr von der Größe. Da steht dann jeder Mitarbeiter drauf, und, ja, wir geben 
morgens an, was wir im Laufe des Tages vorhaben zu tun. Auch, wie viele Stunden wir 
das vorhaben zu tun.« (B-8) 


Das Board wird jedoch nicht nur für die detaillierte Tagesplanung, sondern auch 
für die tägliche Auswertung genutzt. Jeden Tag wird im »Check-in« präsentiert, 
ob die Aufgaben des Vortages erledigt sind und die Zeit eingehalten wurde. Falls 
eine Aufgabe nicht erledigt werden konnte, erklärt der Beschäftigte, warum er 
diese nicht geschafft hat. Da die Beteiligten sich häufig verschätzen, werden im- 
mer wieder Aufgaben auch in die aktuelle Tagesplanung verschoben. 

Das Board hat so nicht nur die Funktion, den Tagesplan abzubilden, sondern 
umfasst auch Kennzahlen. Diese dienen insbesondere dazu, die Produktivität 
des Teams zu messen und Schwierigkeiten aufzuzeigen. Eine wichtige Kennzahl 
ist beispielsweise die Anzahl der kurzfristigen ungeplanten Aufgaben, die in der 
Woche anfallen. Im Rahmen des täglichen Treffens am Board sind die Kenn- 
zahlen zu einem lebendigen Moment der Arbeitspraxis des Teams geworden 
sind. So ist es Teil der täglichen Routine, die Kennzahlen zu aktualisieren. Bei- 
spielsweise wird jeweils nach der Bearbeitung einer kurzfristigen Anfrage diese 
inklusive der benötigten Zeit am Board eingetragen. Dadurch wird sowohl für 
Beschäftigte als auch für Führungskräfte eine neue Qualität der Transparenz ge- 
schaffen. Einzelne Beschäftigte nehmen interessanterweise die Einführung der 
Kennzahlen nicht nur als eine negative Entwicklung wahr. Eine Beschäftigte 
erklärt etwa, dass sie vor der Einführung von Lean keinen Hebel hatten, die un- 
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geplante Arbeitslast aufzuzeigen. Jetzt werde diese auch für den Abteilungsleiter 
transparent. 

Insgesamt jedoch wird die mit dem Shopfloor-Management verbundene neue 
Qualität von Transparenz als Belastung und Moment von Kontrolle erfahren. 
Die Beschäftigten erleben insbesondere die täglichen Treffen am Shopfloor- 
Board als belastend. Dies wird in folgender Passage deutlich: 


»Und bei uns wird es halt aufgezeigt. Dass man auch immer vor Augen hat, was noch 
alles zu tun ist. Und es ist sehr belastend, also für mich persönlich sehr belastend [...). 
Ich hab schon eine ganz andere Tätigkeit wie meine Kollegen. Und die können das auch 
nicht erfassen, dass ich manchmal stundenlang vor meinem Excel drei Stunden sitze, 
und ich komme mir dann irgendwann auch blöd vor; gar nicht vor meinen Kollegen, 
sondern wie ich das dann wieder am nächsten Morgen auf dem Lean-Board vertreten 
soll.« (Ebd.) 


Das mit den täglichen Treffen einhergehende »Outing« wird hier negativ erlebt. 
Die Beschäftigten haben den Eindruck, sich rechtfertigen zu müssen. 


»Man fällt automatisch am nächsten Tag in so eine Rechtfertigungshaltung. [...] Ja. Wa- 
rum man’s nicht geschafft hat. Und warum man nur fünf Stunden eingeplant hat, was 
ja auch mal sein kann, wenn man vielleicht einen privaten Termin hat und dann doch 
acht gebraucht hat. Das ist dann - ja, ist schon so eine Rechtfertigungshaltung.« (Ebd.) 


In der Folge führt das Shopfloor-Management nicht selten auch zu einer Verdich- 
tung von Arbeit. Während früher für Aufgaben mehr Zeit veranschlagt und Pau- 
sen eingelegt wurden, wird jetzt der Tag vollkommen verplant und es ist kein 
»slack« mehr vorgesehen. Auch die Qualität der Arbeit kann leiden, wenn die 
Beschäftigten sich nicht trauen, die wirkliche Zeit anzugeben, die für eine quali- 
tativ hochwertige Bearbeitung notwendig ist. In den beiden folgenden Passagen 
ist der Druck, den die Beschäftigten empfinden, deutlich zu erkennen: 


»Meine Grundeinschätzung ist, da wird mit der Keule über den Bereich gegangen. Und 
diese ganzen Aufgaben, diese Tüftelaufgaben, wie mache ich jetzt eine Prognose, damit 
es für das Bauteil passt, und nicht einfach, ich mache eine Prognose, wie ich sie immer 
für alle anderen Bauteile auch mache [...] Diese zusätzliche Zeit, die nimmt man sich 
nicht mehr. Vielleicht könnte man sie sich noch nehmen, aber durch Lean nimmt man 
sie sich nicht mehr, weil dann muss man es ja wieder aufschreiben und dann ist es wie- 
der komisch, wenn da jetzt sieben Stunden »Prognose erstellen< steht.« 


»Ja, irgendwie hat man das Gefühl. Ich weiß nicht, ob’s auch so gedacht war. Aber man 
hat schon das Gefühl, ja, wenn ich jetzt nur sechs Stunden an Tätigkeiten aufgeschrie- 
ben hab, dann hab ich schon das Gefühl, okay, da fehlt jetzt eine bis zwei - was mache 
ich jetzt in der Zeit noch.« (Ebd.) 
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Standardisierung und kontinuierliche Prozessoptimierung 

Lean wird im untersuchten Team auch dazu genutzt, die Standardisierung von 
Tätigkeiten und die Optimierung der Prozesse im Team, aber auch abteilungs- 
übergreifend voranzutreiben. Das Ziel ist, die Abläufe besser zu gestalten, naht- 
lose Übergänge an den Schnittstellen zu gewährleisten und damit effizienter zu 
werden. Dies gilt als der zentrale Hebel zur Erreichung des vorgegebenen Ziels 
von Rationalisierungseffekten in Höhe von 15 Prozent. 

Durch die Lean-Einführung soll der Arbeitsprozess »aus den Köpfen der Be- 
schäftigten heraus« optimiert werden. Dabei sind zwei Zugänge zur Entäuße- 
rung des Wissens der Beschäftigten zu unterscheiden. Im ersten Fall wird diese 
von den Beschäftigten selbst vorangetrieben. Die Beschäftigten entwickeln eigen- 
ständig sogenannte »Standardarbeitsblätter«, in denen die Schritte zur Erledi- 
gung einer Aufgabe beschrieben werden. Die Wichtigkeit von Standards wird 
im folgenden Interviewausschnitt betont: 


»Bei uns im Team ist es ein ziemlich großer Faktor [...]. Und da ist jeder Kollege von 
uns anders vorgegangen. Und durch dieses Standardarbeitsblatt, da sind’s halt nur 
noch fünf Klicks und dann hat man das - dann hat man diese Auswertung fertig.« 
(B-8) 


Den zweiten Fall repräsentieren Tätigkeitsanalysen, die von außen durchgeführt 
werden. Die interne Lean-Abteilung beobachtet dabei die Beschäftigten und 
macht auf dieser Grundlage Vorschläge für die Standardisierung und Optimie- 
rung der Prozesse. Im folgenden Zitat wird dies bildhaft beschrieben: 


»Die saßen auch bei gewissen Prozessen dann bei einem am Platz, während man die 
gemacht hat. Man hat sich natürlich Prozesse ausgesucht, die auch zu standardisieren 
sind. Und haben sich da Notizen gemacht. Und einem dann das vorgeschlagen, dass 
man diesen Prozess standardisieren kann. Und die Notizen dann auch da einfließen 
lassen. Man muss ja nicht alle Standards selbstständig erstellen, die haben schon am 
Anfang unterstützt, wie man das tun könnte.« (Ebd.) 


Daran wird ein neuer Zugang zur Standardisierung von Wissensarbeit deutlich: 
Tätigkeitsanalysen, bislang vor allem in der Produktion üblich, scheinen im An- 
gestelltenbereich angekommen zu sein. 

Unsere Untersuchungen zeigen schließlich auch, dass die in Lean angelegte 
Idee der kontinuierlichen Verbesserung Eingang in das Team findet und auch 
von den Beschäftigten vorangetrieben wird. Um dies zu unterstützen, hat das 
Team ein sog. »Problem-Board« eingeführt, auf dem arbeitsbezogene Probleme 
notiert sind. Im Rahmen der täglichen Treffen werden diese diskutiert und suk- 
zessive bearbeitet. 
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Dabei geht es sowohl um teambezogene als auch um abteilungsübergreifende 
Themen. Beispielsweise nutzte das Team Lean zur Standardisierung der Inter- 
aktion mit anderen Teams, mit denen es die Berichte abstimmen muss. Bislang 
hatte das Team das Problem, dass man diesen »hinterherrennen« musste. Deshalb 
wurde teamübergreifend ein Standard entwickelt, dem zufolge der Termin regel- 
mäßig an einem bestimmten Tag stattfindet. 

Interessant ist, dass dieser Wandel von den Beschäftigten im doppelten Sin- 
ne bearbeitet wird. Einerseits sind die Beschäftigten verpflichtet, das Ziel der 
Schaffung von 15 Prozent freier Kapazität zu erreichen, und treiben die Prozess- 
optimierung kontinuierlich voran, um diese Verpflichtung einzulösen. Die Ver- 
besserung der Prozesse wird dabei durchaus auch positiv erlebt: 


»Und viele sagen aber auch, dass man dadurch Dinge durchbringen konnte, die vorher 
in der Abteilung eher auf Unverständnis gestoßen sind. Das ist der positive Aspekt. 
Alles wird viel ernster genommen, was man jetzt - gerade was mit Zeiten und mit 
irgendwelchen Eflizienzen zu tun hat. Dieser Satz, »das machen wir schon immer so<, 
der fällt in letzter Zeit nicht mehr so oft. Das ist ja so ein [Unternehmensname]-Satz. 
[...]. Und ja, das ist ein bisschen zurückgegangen. Das sehen viele auch positiv. Muss ich 
auch sagen, ja. Nicht alles schlecht.« (Ebd.) 


Andererseits unternehmen die Beschäftigten gemeinsam mit den Führungskräf- 
ten parallel dazu Kompensationsanstrengungen, indem sie nach zusätzlichen 
Aufgaben suchen, damit ihre Stellen nicht abgebaut werden. Auf einem eigenen 
Board werden Vorschläge gesammelt, wie die frei werdenden Kapazitäten wie- 
der mit neuen Aufgaben gefüllt werden können. Damit sollen Stellenstreichun- 
gen verhindert werden. 


3.2.3.2 Fallbeispiel Il: Lean in der Entwicklung und Montage von Prototypen 

Bei diesem Fallbeispiel geht es um die Einführung von Lean in der Entwicklung 
und Montage von Prototypen. Lean wurde hier bereits vor einigen Jahren einge- 
führt, ausgehend von der internen Lean-Abteilung und in Zusammenarbeit mit 
einer externen Unternehmensberatung. Das Ziel der Einführung war auch hier 
die Verbesserung und effiziente Gestaltung der Prozesse. Lean wird in diesem 
Fall nicht mit derselben Vehemenz vorangetrieben wie bei den Verwaltungs- 
tätigkeiten, aber auch die Arbeit in der Entwicklung verändert sich durch die 
Einführung von Lean grundlegend. 

Die Entwicklung von Prototypen zeichnet sich durch lange Entwicklungs- 
zyklen aus, die sich über fünf bis sechs Jahre erstrecken und dann in die Serien- 
produktion münden. Dabei sind zwei Phasen zu unterscheiden, die eng mitei- 
nander verkoppelt sind. In der ersten Phase wird das Produkt konzipiert, in der 
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zweiten Phase wird es als Prototyp konstruiert." An der Erstellung von Proto- 
typen sind mehrere Bereiche beteiligt: die Entwicklung, die ihn konzipiert, der 
Einkauf, der die Einzelteile beschafft, und nicht zuletzt die Montage, die ihn zu- 
sammenbaut. Nach dem Test wird der Prototyp an interne und externe Kunden 
weitergegeben, und deren Rückmeldungen werden in die weitere Entwicklung 
aufgenommen. 

Im Folgenden wird das Team in den Blick genommen, das an der Schnitt- 
stelle zwischen Entwicklung und Einkauf arbeitet. Es ist für die Vermittlung der 
Aufträge an den Einkauf und die Montage verantwortlich und hat so den gesam- 
ten Prozess im Blick. Die zentralen Elemente von Lean sind hier die Einführung 
von Shopfloor-Management und die kontinuierliche Optimierung von Prozessen. 


Shopfloor-Management 
Das Shopfloor-Board dient in diesem Team der Abbildung des Arbeitsprozes- 
ses im Team. Die anstehenden Aufgaben werden auf Kärtchen visualisiert, auf 
denen eine kurze Aufgabenbeschreibung, die Deadline sowie die voraussichtli- 
che Bearbeitungsdauer festgehalten sind. Im Unterschied zum Fallbeispiel I sind 
die Aufgaben hier sowohl bezüglich des Inhalts als auch des Umfangs sehr va- 
riabel. Darüber hinaus wird auf dem Kärtchen der Verantwortliche angegeben, 
der sog. »Kümmerer«. Das Board ist durch den Ablauf des Arbeitsprozesses struk- 
turiert. Im Zuge der Bearbeitung schieben die Beschäftigten die Kärtchen durch 
den Prozess. Nach Abschluss der Aufgabe wird die Karte in den »Done-Bereich« 
geschoben und vom Board abgehängt. Zudem werden teamspezifische Kenn- 
zahlen festgehalten, die zur Steuerung verwendet werden und an eine »Ampek 
gekoppelt sind, die den Bearbeitungsstand angibt. Eine wichtige Kennzahl ist 
beispielsweise die Anzahl der zu bearbeitenden Aufträge. 

Das Board ist der Mittelpunkt der täglich im Team stattfindenden »Stehun- 
gen«, an denen alle Beschäftigten teilnehmen, die an der Bearbeitung der Projek- 
te beteiligt sind.” Die »Stehungen« dauern in der Regel etwa 45 Minuten und 


13 | Dieses Verfahren ähnelt weniger der industriellen Produktion als vielmehr den 
Abläufen in einer Manufaktur. Ein Interviewpartner schildert es so: »Das heißt, alle 
[Produkte] wurden bei uns aufgebaut aus Einzelteilen. Und natürlich, wie eine Manu- 
faktur kann man sich’s vorstellen: alle Teile werden einzeln eingekauft, werden in der 
Montage zusammengebaut. Der [Prototyp] wird dann auf den Prüfstand genommen, 
wird in den Betrieb genommen. Man fährt die verschiedenen Tests. Und dann bekom- 
men ihn unsere internen Kunden.« (B-4) 

14 | In die Stehungen werden auch die Leiharbeitskräfte (also die überlassenen Arbeit- 
nehmer) im Team eingebunden, während die Fremdarbeitskräfte ein Arbeitspaket zu- 
gewiesen bekommen und nicht weiter koordiniert werden dürfen. 
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damit vergleichsweise lange. Dies resultiert daraus, dass das Shopfloor-Manage- 
ment sehr ernst genommen wird und jede einzelne Karte, die am Board hängt, 
durchgesprochen wird. Der Fokus der täglichen »Stehungen« liegt sowohl auf 
dem Austausch und der Unterstützung bei Problemen als auch auf der Priorisie- 
rung und Kalibrierung von Aufgaben. Aufschlussreich ist hierzu folgende Dar- 
stellung: 


»Besprochen wird: gibt’s da Probleme, habt ihr Probleme, müssen wir unterstützen, 
müssen wir was priorisieren? Kommt vielleicht der einzelne Mitarbeiter jetzt nicht 
wirklich weiter? Dann gibt's vielleicht im Team einen, der den da unterstützen kann an 
der Stelle, fachlich wie auch, sage ich mal, von der Kapazität her. Bei wem ist es gerade 
eher ruhiger, wessen Aufträge können vielleicht nicht weiterbearbeitet werden momen- 
tan im Prozess, weil ein Teil nicht da ist oder warum auch immer? Wo man dann unter- 
stützen kann an der einen oder anderen Stelle. Einfach, dass man das - auch das Team 
da sich dann ein bisschen steuern kann.« (B-4) 


Interessant ist, dass das Board zur Abbildung des Arbeitsflusses des Gesamt- 
teams genutzt wird und nicht, wie im vorigen Fallbeispiel, zur individuellen 
detaillierten Tagesplanung. Es deutet sich an, dass dabei die Ebene des Teams 
an Bedeutung gewinnt. Die Beschäftigten nutzen die Treffen, um sich auszu- 
tauschen und sich gegenseitig zu unterstützen. Darüber hinaus dient das Board 
als Basis für die Selbstorganisation des Teams. Wenngleich der Charakter des 
Teams und die Art der Zusammenarbeit qualitativ nicht mit Scrum-Teams zu 
vergleichen sind, zeigt sich daran, dass die Beschäftigten den Teamgedanken 
ernst nehmen, indem sie ihre Planung als gemeinsame begreifen und sich wech- 
selseitig Unterstützung bieten. 

Anders als z.B. in Fallunternehmen D zeichnet sich die Organisation der 
Arbeitsprozesse durch einen geringen Informatisierungsgrad aus. Dies wird ins- 
besondere an der Organisation von teamübergreifenden Prozessen deutlich. Da 
das Shopfloor-Management auf das Team konzentriert ist, sind die Teams perma- 
nent mit der Aufgabe konfrontiert, zusätzlich die teamübergreifenden Prozesse 
zu bearbeiten. Häufig wandern die Aufgaben von einem Board zum nächsten. 
Diese sprichwörtlichen »Übergaben« werden durch die Beschäftigten persönlich 
übernommen, indem sie die Aufgabenkarte weiterreichen oder die Verantwort- 
lichen, die die Aufgabe bearbeiten, zu sich in die »Stehung« einladen. 

Diese Praktik zeigt deutlich die Grenzen der teamübergreifenden Zusammen- 
arbeit auf Basis von physischen Shopfloor-Boards. Instruktiv ist hier ein Vergleich 
mit Fallunternehmen D, das mit IT-gestützten Tools wie Jira die Arbeitsorgani- 
sation über die Teams hinweg durchgängig organisieren kann. Demgegenüber 
werden in diesem Beispiel die Arbeitsprozesse nicht mit IT-gestützten Systemen 
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unterlegt, die einen durchgängigen »flow of information« sicherstellen. Folglich 
müssen die Schnittstellen personal überbrückt werden. Diese Problematik wird 
zwar in der Praxis reflektiert, gleichwohl zeigen sich keine Bestrebungen, die In- 
formatisierung des Arbeitsprozesses voranzutreiben, um diese Herausforderung 
zu bearbeiten. Damit bleibt die Frage der systemischen Integration der Arbeits- 
organisation unbeantwortet. 

Dies tut der Bedeutung und Wirkung des Shopfloor-Managements jedoch in 
der Praxis keinen Abbruch. Auch in diesem Fallbeispiel wird die Arbeit jedes 
Einzelnen in neuer Qualität transparent. Allein durch das Shopfloor-Board und 
die täglichen »Stehungen« werden die Aufgabeninhalte und Arbeitsabläufe 
sichtbar. Auf der einen Seite können so in den »Stehungen« Probleme frühzeitig 
erkannt und durch das Team gelöst werden. Auf der anderen Seite entstehen 
damit auch neue Kontrollmöglichkeiten. Nicht nur mit Blick auf den Aufwand, 
der mit dem Shopfloor-Management verbunden ist," stehen die Beschäftigten 
dem neuen Instrument durchaus auch kritisch gegenüber - vielmehr erzeugen 
auch die spürbaren neuen Kontrollpotenziale Misstrauen und Kritik: »Warum 
kontrolliert ihr uns überhaupt, ja? Habt ihr kein Vertrauen, dass wir das selber 
machen (Ebd.) 


Optimierung der Prozesse 

Neben dem Shopfloor-Management bildet die Verbesserung der Prozesse das 
zweite zentrale Element von Lean in diesem Fallbeispiel: Sie wird dabei zum Teil 
in »Iop-down«-Initiativen angestoßen und zum Teil von den Beschäftigten selbst 
»bottom-up« vorangetrieben. 

Die Optimierung der Prozesse wird regelmäßig vom Management auf die 
Agenda gesetzt. Bereits im Zuge der Einführung von Lean hat z.B. die inter- 
ne Lean-Abteilung ein größeres Projekt in Zusammenarbeit mit einer externen 
Beratungsfirma durchgeführt. Dabei ging es darum, bestehende Prozesse im 
Team in den Blick zu nehmen und zu verbessern. Zum Zeitpunkt der Unter- 
suchung wurde darüber hinaus im gesamten Geschäftsbereich »top-down« ein 
weiteres Großprojekt umgesetzt. Es zielte auf die Integration der global verteil- 
ten Entwicklungsstandorte und nahm die Neuorganisation und Optimierung 
der Prozesse in den Fokus. Ähnlich wie in der Verwaltung - wenn auch nicht 


15 | So berichtet ein Entwickler: »Und bei vielen ist es halt so, dass die, gerade so diese 
Entwickler, also die Bauteil-Entwickler, sage ich mal - die schen das als überflüssig an. 
Warum soll ich mich jetzt hier eine halbe Stunde oder Stunde reinstellen, wenn dann 
nur fünf Minuten - redet ihr nur über mein Teil, alles andere interessiert mich hier 
nicht. So auf die Art.« (B-4) 
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mit der gleichen Konsequenz - wurden hier zahlreiche Prozesse einzeln analy- 
siert, Handlungsfelder bestimmt und optimiert. Besonders interessant ist, dass 
die Beschäftigten Verbesserungsprojekte auch in Eigeninitiative »bottom-up« 
vorantreiben und dies als wichtigen Beitrag zur Umsetzung von Lean verstehen. 
So hat beispielsweise ein Beschäftigter in Zusammenarbeit mit einem externen 
Programmierer ein IT-gestütztes System zur Auftragsbearbeitung und zur Ver- 
besserung der Interaktion an der Schnittstelle zwischen Entwicklung und Ein- 
kauf entwickelt. Während früher die Bestellungen der Entwickler auf Papier 
notiert und in verschiedenen Excel-Dateien gespeichert wurden, sind jetzt die 
einzelnen Schritte im Tool vorgegeben und alle Daten zentral abgelegt. Über 
das IT-System werden alle Aufträge abgewickelt. Auf dieser Basis werden ver- 
schiedene Abteilungen miteinander vernetzt und schließen nahtlos aneinander 
an. Damit wird die Wertschöpfungskette von der Entwicklung bis zum Einkauf 
durchgängig gestaltet. 


3.2.3.3 Die Rolle des Betriebsrats 

Der Wandel der indirekten Bereiche wird vom Betriebsrat sehr aktiv und enga- 
giert begleitet. Schon im Kontext des initiierten Rationalisierungs- und Kosten- 
senkungsprogramms in der Verwaltung und während der betrieblichen Aus- 
einandersetzungen um die Verlagerung von Arbeitsplätzen hatte der Betriebsrat 
eine bedeutsame Rolle für den Angestelltenbereich gespielt. Sie hat sich im Zuge 
der Lean-Einführung weiter gefestigt. Zwei Momente sind hierbei von zentraler 
Bedeutung: der Abschluss einer Gesamtbetriebsvereinbarung zur Einführung 
von Lean in den indirekten Bereichen und die aktive Begleitung von Lean-Pro- 
jekten in der täglichen Arbeitspraxis durch den Betriebsrat. 

Nach der Einführung von Lean erreichten erste Rückmeldungen der Ver- 
waltungsbelegschaft, die bis dahin als nicht betriebsratsaffin galt, die Arbeit- 
nehmervertretung: Beklagt wurde, dass Vorgaben nicht einzuhalten seien, die 
Arbeitsmenge nicht mehr zu bewältigen sei oder auch, dass die Beschäftigten 
bei der Einführung neuer Instrumente nicht ausreichend beteiligt würden. Auf 
dieser Grundlage wurden Betriebsrat und Gesamtbetriebsrat aktiv. Sie handel- 
ten schließlich eine innovative Gesamtbetriebsvereinbarung aus, die nun auch 
für Lean-Projekte in den indirekten Bereichen »Spielregeln« festlegt, deren Ein- 
haltung sicherstellt und die Beteiligung des Betriebsrats festschreibt. 

Die Gesamtbetriebsvereinbarung baut auf einer zuvor schon existierenden 
Vereinbarung zu Lean in der Fertigung auf. Sie enthält eine Liste »erlaubter« 
Methoden (auf der Grundlage der Regelungen des bestehenden »Ganzheitlichen 
Produktionssystems« in der Fertigung) und legt fest, dass die Anwendung der 
Methoden nicht vorrangig das Ziel haben darf, Arbeitsplätze abzubauen. Weiter 
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formuliert sie Schutzbestimmungen zu Arbeitsplatzsicherheit und Verdienstaus- 
gleich für die Beschäftigten: Im Falle von personalwirksamen Veränderungen 
haben diese Anspruch auf einen gleichwertigen zumutbaren Arbeitsplatz, auf 
eine Bevorzugung bei der Besetzung freier Stellen sowie auf Entgeltsicherheit. 
Auch eine Konkretisierung der Mitbestimmungsrechte des Betriebsrats wurde 
in der Gesamtbetriebsvereinbarung vorgenommen. Es ist z.B. festgelegt, dass 
der Betriebsrat über geplante Lean-Projekte »förmlich« informiert werden muss. 
Dies bedeutet, dass ein Formblatt vorgeschrieben ist, aufdem das Unternehmen 
das geplante Projekt und dessen Zielsetzung genau benennen und vor allem 
schriftlich darüber Auskunft geben muss, ob es einen Abbau von Arbeitsplätzen 
beinhaltet. 

In unseren Interviews wird deutlich, dass der Betriebsrat am untersuchten 
Standort aktiv von seinen Mitbestimmungsrechten Gebrauch macht. Er nutzt 
das Informationsrecht und nimmt darüber hinaus aktiv an der Einführung 
von Lean-Projekten teil. Wichtig ist insbesondere seine Präsenz zu Beginn von 
Projekten, um darauf hinzuwirken, dass diese den Vorgaben entsprechen. Dar- 
über hinaus nimmt der Betriebsrat auch spontan an »Stehungen« an den Shop- 
floor-Boards teil. Ferner besucht er die Abteilungen spontan in regelmäßigen Ab- 
ständen, um Präsenz zu zeigen und sich mit den Beschäftigten auszutauschen. 
In der Betriebsratszeitung wird zudem regelmäßig über wichtige Lean-Projekte 
informiert. 

Die Aktivitäten des Betriebsrats sind mit Blick auf die konkrete Gestaltung 
von Lean im Fallunternehmen von großer arbeitspolitischer Bedeutung. Aus der 
Sicht des Betriebsrats ist dieser Umbruch noch lange nicht abgeschlossen, und 
zentrale Fragen müssen auch künftig weiter bearbeitet werden, vor allem Fragen 
zu Arbeitszeiten und Leistungsbedingungen in der Angestelltenwelt sowie zur 
angemessenen Entlohnung, wenn Zeitaufnahmen und Wertstromanalysen in 
die Büros einziehen. Im Zuge des Wandels der Arbeit in den indirekten Berei- 
chen deutet sich eine Öffnung der dort Beschäftigten gegenüber dem Betriebsrat 
an: Infolge seiner Aktivitäten rund um die Einführung von Lean konnte der Be- 
triebsrat den Zugang zu den »Angestellten« deutlich verbessern. 


3.2.4 Zusammenfassung 


Nachdem im Fallunternehmen lange die Produktion im Zentrum von Rationa- 
lisierungsprogrammen gestanden hatte, sind seit den 2000er Jahren vermehrt 
die indirekten Bereiche in den Fokus geraten. Insbesondere in der Verwaltung 
wurden mit der Einführung von Shared-Services-Konzepten Arbeitsabläufe 
grundlegend restrukturiert, Kosten gesenkt und Arbeitsplätze abgebaut. In der 
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Folge ist in den betroffenen Bereichen eine deutliche Arbeitsverdichtung zu er- 
kennen. Um in Zukunft wachsen zu können, ohne den Personalstamm wie- 
der zu erhöhen, ist deshalb die Optimierung der Prozesse und die Steigerung 
der Produktivität zu einer strategischen Herausforderung geworden. Mit Blick 
auf die Erfolge der Ganzheitlichen Produktionssysteme in der Fertigung wurde 
begonnen, die entsprechenden Methoden auch auf die indirekten Bereiche zu 
übertragen. Dabei wird Lean in den indirekten Bereichen unter der Überschrift 
»kontinuierliche Verbesserung« flächendeckend eingeführt, um »Verschwen- 
dung« zu beseitigen. Einem zentralen Roll-out-Plan folgend, wurde Lean so zu 
einem wesentlichen Bestandteil der Reorganisation der indirekten Bereiche. 

Die Einführung von Lean markiert dabei eine neue Phase. Während in der 
vorherigen Phase die indirekten Bereiche »von außen« reorganisiert wurden, 
liegt der Fokus jetzt auf der Optimierung der Arbeitsorganisation auf Basis der 
Erfahrungen der Beschäftigten. Die Kernmomente von Lean sind in der Praxis 
das Shopfloor-Management, die Standardisierung von Aufgaben und die konti- 
nuierliche Verbesserung der Prozesse. Besondere Bedeutung kommt dabei dem 
Shopfloor-Management zu, das - in der Verwaltung ebenso wie in der Entwick- 
lung - zentraler Bestandteil von Lean ist. Es führt zu einer neuen Qualität der 
Transparenz und insbesondere auch der Steuerbarkeit. In der Praxis zeigen sich 
Unterschiede zwischen der Umsetzung in der Verwaltung und der Entwicklung. 
Während im Fallbeispiel Verwaltung eine engmaschige Umsetzung erkennbar 
ist, die eine individuelle Planung in Stunden vorsicht, liegt im Beispiel aus der 
Entwicklung der Fokus auf der allgemeinen Abbildung des Arbeitsprozesses. 
Gleichwohl ist auch in diesem Beispiel die Schätzung des zeitlichen Aufwands 
für die Aufgaben von zentraler Bedeutung. 

Auf dieser Basis wird mit Lean zudem konsequent die Standardisierung und 
kontinuierliche Verbesserung der Prozesse vorangetrieben. Dies ist in der Praxis 
letztlich der entscheidende Hebel, um »Verschwendung« zu vermeiden, die Pro- 
duktivität zu steigern und so Kapazitäten für neues Wachstum zu schaffen. Die 
Beispiele zeigen, dass die Bereiche hierfür konkrete Zielvorgaben bekommen 
und in einem bestimmten Zeitraum freigewordene Kapazitäten nachweisen 
müssen. Sowohl top-down als auch bottom-up unter Beteiligung der Beschäftig- 
ten werden hierzu laufend KVP-Projekte umgesetzt. Interessant ist dabei, dass 
analog zu Fallunternehmen A in der Praxis die Potenziale der Informatisierung 
und die Ideen von Lean bei der Optimierung der Prozesse nicht systematisch 
und auf strategischer Ebene aufeinander bezogen werden. Die Projekte in der 
Praxis - wie z.B. die Entwicklung eines IT-gestützten Systems an der Schnitt- 
stelle zwischen Entwicklung und Verkauf - deuten jedoch darauf hin, dass der 
nächste Entwicklungssprung an dieser Stelle zu erwarten ist. 
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3.3 Fallstudie C: Lean & Agil - 
Ein neues Entwicklungsmodell in der Software-Entwicklung 


3.3.1 Unternehmenscharakteristik und Ausgangsbedingungen 


Fallunternehmen C ist ein großes europäisches IT-Unternehmen mit mehre- 
ren Zehntausend Mitarbeitern. Allein im Bereich der Software-Entwicklung 
arbeiten hier fast 20.000 hochqualifizierte Beschäftigte weltweit. Das Unter- 
nehmen ist als klassisches »Lack-Turnschuh-Unternehmen« (Boes/Baukrowitz 
2002) davon geprägt, in nur wenigen Jahrzehnten von einem mittelständischen 
IT-Unternehmen zu einem weltweit führenden Global Player der Branche auf- 
gestiegen zu sein. Teil dieses Wachstumsprozesses ist auch eine rasche und in- 
tensive Globalisierung des Unternehmens. Dies betrifft nicht nur den Vertrieb 
und das Ziel, ausländische Märkte zu erobern, sondern insbesondere auch den 
Aufbau globaler Entwicklungsstrukturen. Heute besitzt das Unternehmen Labs 
auf der ganzen Welt. 

Insbesondere im Zuge des Globalisierungsprozesses hat im Unternehmen 
für die Beschäftigten eine »Zeitenwende« (Boes/Trinks 2006; Boes/Kämpf 2011) 
deutlich an Kontur gewonnen. Gerade der Aufbau neuer Standorte in Niedrig- 
lohnländern hat im Unternehmen Spuren hinterlassen. Auch wenn in Deutsch- 
land selbst keine Stellen direkt abgebaut wurden, hat das asymmetrische Wachs- 
tum der neuen Standorte zu Unsicherheiten und »Rissen« in der betrieblichen 
Sozialordnung geführt. Dabei ist weniger die unmittelbare Angst, den Arbeits- 
platz zu verlieren, entscheidend für die Befindlichkeit der Beschäftigten. Oft- 
mals geht es auch um den Verlust von Anerkennung und Wertschätzung und 
die Erfahrung, auch als hochqualifizierter Software-Entwickler mit Kostensen- 
kungsstrategien konfrontiert zu werden. Auch die zunehmende Prozessorien- 
tierung und Standardisierung wird sehr kritisch beobachtet. Sie wird als fort- 
schreitende Bürokratisierung erlebt, die die Freiheitsgrade in der Arbeit mehr 
und mehr einengt. 

Das Unternehmen hat Ende der 2000er Jahre begonnen, in den Entwick- 
lungsabteilungen neue Formen des Lean Development einzuführen. Davor hatte 
man bereits, oftmals über Jahre hinweg, in einigen Teams mit agilen Methoden 
wie Scrum experimentiert. Im Kontext von Lean werden die neuen Entwick- 
lungsformen - die Lean und Scrum kombinieren - flächendeckend über weite 
Teile der Entwicklungsorganisation ausgerollt. Jenseits der klassischen Wasser- 
fallkonzepte wurde so ein neues Entwicklungsmodell in der Praxis etabliert. 
Das Unternehmen wird damit zu einem Vorreiter für die Entwicklung und 
Umsetzung von Lean-Konzepten im Bereich hochqualifizierter Wissensarbeit. 
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Bemerkenswert ist dabei die konsequente und rasche Implementierung - nicht 
zuletzt im Kontrast zu den eher dezentralen Implementierungsprozessen in den 
F&E-Bereichen der klassischen Industrie. Nicht nur die Entwicklungsprozesse 
selbst wurden verändert, sondern z.B. auch die komplementären HR-Prozesse 
und Organisationsstrukturen der Entwicklung. Insgesamt ist der Fall ein weit 
fortgeschrittenes Beispiel dafür, wie mit Lean Entwicklungsprozesse in der Soft- 
ware-Entwicklung neu gestaltet werden können. Das umfangreiche empirische 
Material erlaubt es, hier insbesondere die Veränderungen der Arbeit selbst und 
die Perspektive der Beschäftigten bzw. die Folgen für die Beschäftigten differen- 
ziert und empirisch gehaltvoll zu rekonstruieren. 


3.3.2 Auf dem Weg zu einem neuen Entwicklungsmodell 
in der Software-Entwicklung 


Mit der Einführung von Lean Development hat sich im Unternehmen ein neues 
Entwicklungsmodell durchgesetzt. Die Basis hierfür bilden die neuen Abläufe 
agiler Methoden wie Scrum. Sie sind an die Stelle der zunehmend bürokrati- 
schen Prozesse des alten Wasserfallmodells getreten: Statt mehrjähriger Projekt- 
zyklen strukturieren nun kurzzyklische Sprints von zwei bis vier Wochen den 
Entwicklungsprozess, die klassischen Projektleiter wurden ersetzt durch neue 
Rollen wie Product Owner und Scrum Master, und statt des individuellen »Soft- 
ware-Künstlers« wird nun das kollektive Team zum zentralen Akteur der Ent- 
wicklung. Flächendeckend durchsetzen konnte sich das neue Modell jedoch 
erst in der Verklammerung und Verknüpfung der Konzepte von Scrum mit den 
Ideen von Lean - dies wird insbesondere dann deutlich, wenn man zunächst 
den Einführungs- und Implementierungsprozess differenziert betrachtet und 
rekonstruiert. 


3.3.2.1 Vom »Wasserfall« zu Lean Development: 
Implementierung und Einführungsprozess des neuen Entwicklungsmodells 

Schon lange vor der flächendeckenden Einführung von Lean Development wur- 
den im Unternehmen Erfahrungen mit agilen Methoden wie Scrum, Extreme 
Programming oder auch Pair Programming gemacht. Protagonisten waren dabei 
oftmals einzelne Projektleiter, die nicht nur - wie in der Entwickler-Welt ver- 
breitet - von neuen Methoden fasziniert waren, sondern auch eine konkrete 
Unzufriedenheit mit den klassischen Entwicklungsprozessen im Unternehmen 
hegten, die sie als bürokratisch erlebten und die nach ihrer Ansicht den eigentli- 
chen Anforderungen in der Entwicklung kaum gerecht wurden. Sie verstanden 
die agilen Pilotprojekte mithin als Alternative dazu, sogar als subversive Gegen- 


85 


Kapitel 3 


bewegung. Man begann nun auch, eine »agile Community« im Unternehmen 
aufzubauen und sich zu vernetzen, um Erfahrungen auszutauschen und die Ak- 
zeptanz und Verbreitung der neuen Methoden im Unternehmen weiter voran- 
zutreiben. 

Parallel zu diesen ersten Pilotprojekten gerieten im Unternehmen die eta- 
blierten Entwicklungsprozesse immer öfter an ihre Grenzen. Die steigende 
Komplexität der Organisation - u.a. begründet durch das Wachstum und die 
Globalisierung der Entwicklungsmannschaft - ließ sich im alten Paradigma 
kaum noch beherrschen. Die Versuche, darauf mit einer steigenden Prozess- 
orientierung zu reagieren und den Entwicklungsprozess kleinschrittig durch 
»Micro-Management« stärker zu kontrollieren, führten zu zunehmend schwer- 
fälligen und langsamen Prozessen. Nicht nur die Entwickler waren unzufrie- 
den, sondern auch große, strategisch wichtige Software-Projekte drohten zu 
scheitern bzw. konnten nicht »in time« und »in budget« finalisiert werden. Zu- 
dem wurde in Managementkreisen befürchtet, dass die innovative Kultur - als 
zentrales strategisches »Asset« des Unternehmens - und die Orientierung am 
Kundennutzen verloren zu gehen drohten. Vor diesem Hintergrund wuchs nun 
auch im oberen und mittleren Management die Aufmerksamkeit und Offenheit 
für die »Experimente« der »agilen Community« im Unternehmen, die auf posi- 
tive Erfahrungen aus ihren Pilotprojekten verweisen konnte. Trotz des wachsen- 
den Interesses konnten diese »bottom-up« getriebenen Pilotinitiativen jedoch 
vorerst noch keine Breitenwirkung entfalten. 

In der Praxis erfolgte der Durchbruch erst, als die Scrum-Initiativen mit den 
Konzepten von Lean verknüpft wurden. Lean spielte hier eine doppelte Rolle. 
Auf der einen Seite lieferten die Lean-Konzepte Werkzeuge und Stategien, wie 
sich die praktischen Erfolge der agilen Methoden auf eine gesamte Entwick- 
lungsorganisation skalieren lassen. Bis dahin galt Scrum als neue und innovative 
Methode, um ein Team bzw. kleinere Software-Projekte zu organisieren - offen 
war jedoch, wie auf dieser Grundlage globale Entwicklungsabteilungen mit Tau- 
senden Entwicklern ganzheitlich strukturiert werden können. Im Kontext von 
Lean wurden hier im Unternehmen kaskadierte Systeme wie Scrum of Scrums 
eingeführt, teamübergreifende Schnittstellen und Prozesse neu gestaltet und 
mit Lean Management auch neue Führungsprinzipien verankert. Auf der ande- 
ren Seite machten die in der Industrie breit erprobten Ideen von Lean - und die 
damit verbundene Rhetorik einer effizienten und schlanken Organisation - die 
neuen Entwicklungsformen anschlussfähig an die Vorstellungen und Erwar- 
tungen des Managements. Salopp formuliert, bewegte man sich mit Lean nicht 
mehr im Milieu einer Grassroot-Bewegung der Software-Community, sondern 
im »seriösen« Kontext einer in der Industrie verbreiteten Methode zur Steige- 
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rung der Produktivität. Folgerichtig wurde mit der Einführung und Entwick- 
lung des Modells eine etablierte, aus der Industrie stammende Unternehmens- 
beratung beauftragt. 

Mit dem Commitment des oberen Managements wurde das neue Entwick- 
lungsmodell nun in einem stufenförmigen Prozess top-down eingeführt. Im 
Fokus stand zunächst der Bereich der technologischen Kern- und Infrastruk- 
turentwicklung. Dieser Bereich hatte in der Vergangenheit bereits die meisten 
Erfahrungen mit agilen Methoden sammeln können und war entsprechend affin 
zu den Konzepten der Reorganisation. Darüber hinaus ist dieser Bereich wenig 
durch externe Kunden getrieben. Dem folgten verschiedene Bereiche der Anwen- 
dungsentwicklung. Bis auf wenige Ausnahmen wurde das neue Entwicklungs- 
modell schließlich auch in den ausländischen Labs flächendeckend umgesetzt. 

Was den Implementierungsprozess auf der einen Seite auszeichnet, ist die 
Breite und Konsequenz, mit der ein auf Scrum und Lean basierendes Entwick- 
lungsmodell in der Fläche umgesetzt wurde. Der »Wasserfall« als bis dato zen- 
trales Paradigma der Entwicklung wurde hier in sehr kurzer Zeit vollständig 
durch ein neues System ersetzt. Gerade zu Beginn der Implementierung wurde 
dabei auch Wert darauf gelegt, zentrale Prinzipien von Scrum - wie etwa die 
Schätzung von Arbeitsaufwänden, die Zerlegung von Arbeitspaketen durch das 
Team, Commitment und Empowerment oder auch das Prinzip der Usable Soft- 
ware — wirklich umzusetzen. Dafür erhielten die Teams umfangreiche Schulun- 
gen. Auf der anderen Seite zeichnet sich die Einführung durch ihren ganzheit- 
lichen Charakter und die Tiefe der Veränderungen aus. Gerade im Kontrast zu 
vielen Unternehmen aus der klassischen Industrie hat sich das Unternehmen 
nicht darauf beschränkt, lediglich die Kern-Entwicklungsprozesse inkrementell 
neu zu gestalten. Vielmehr hat man insbesondere auch die »benachbarten« Ge- 
schäftsprozesse und Abläufe - vom Produktmanagement über die Release-Pla- 
nung bis hin zu den Gehaltsmodellen und HR-Rollen - systematisch an das 
neue System angepasst. So wurde z.B. in der Entwicklung die bisher zentrale 
Rolle des Projektleiters - die im Unternehmen zu einem eigenständigen Karrie- 
repfad entwickelt worden war - zugunsten der neuen Rollen des Product Owners 
und des Scrum Masters aufgelöst. Diese Umwälzungen betrafen auch das Ma- 
nagement selbst. Mit dem Empowerment der Teams und den neuen Prinzipien 
des Lean Managements wurden die Führungsspannen deutlich erhöht: War ein 
Teamleiter im alten Modus in der Regel für zehn Entwickler verantwortlich, 
wurde diese Spanne nun auf 30 Entwickler gesteigert. Viele Teamleiter in der 
Entwicklung mussten sich in der Folge neu in Richtung Product Owner oder 
Scrum Master entwickeln - ohne wirklich zu wissen, was dies für die eigenen 
Karrierepfade, -optionen und -chancen in der Zukunft bedeutete. 
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Auch wenn die Implementierungsphase dadurch mit Unsicherheiten und 
auch anfänglichen Unklarheiten bei der konkreten Ausgestaltung'* verbunden 
war, begrüßten die meisten Beschäftigten die Einführung von Lean zunächst 
überwiegend als einen »Schritt in die richtige Richtung«. Über die verschiede- 
nen Erhebungswellen hinweg, die uns die Sammlung empirischen Materials 
erlaubten (vgl. Kapitel 2.3), konnten wir diese positive Grundstimmung rekons- 
truieren. Hintergrund hierfür ist, dass die Einführung von Lean als Teil eines 
»Kurswechsels« erfahren wurde, durch den Fehlentwicklungen der vergangenen 
Jahre im Unternehmen korrigiert werden würden. Zugespitzt formuliert, wur- 
de Lean von den Entwicklern im Sinne eines »back to the roots« interpretiert, 
als »Rückkehr zu den alten Werten«, wie es einer von ihnen ausdrückte (C-53). 
Aus der Perspektive der Beschäftigten waren dabei von besonderer Bedeutung: 
eine Stärkung von Teamarbeit, weniger Bürokratie, mehr Kundenorientierung 
und eine Relokalisierung der Entwicklungsarbeit.' 

Es gab auch kritische Stimmen in der Belegschaft, die u.a. die Analogien 
zur Automobilindustrie kritisierten, wie sie in den Schulungskonzepten gezo- 
gen wurden. Die insgesamt positive Haltung der Beschäftigten darf aber in ihrer 
Bedeutung für den Implementierungsprozess nicht unterschätzt werden. Dies 
gilt besonders im Vergleich zu den anderen Fallstudien, in denen gerade in den 
Entwicklungsbereichen oftmals eine deutlich verhaltenere Stimmungslage an- 
zutreffen war. Die Hoffnung auf eine Entformalisierung der Entwicklungsarbeit 
wurde im Fallunternehmen zur Voraussetzung für die aktive Beteiligung der Be- 
schäftigten bei der Umsetzung des neuen Entwicklungsmodells. Entscheidend 
hierfür war nicht zuletzt der ursprüngliche Rekurs auf die agilen Methoden, 
die mit ihrer Kritik am bürokratischen »Wasserfallmodell« für die Entwickler 


16 | Ein bedeutsames Anfangsproblem war, neben der Ausgestaltung und Besetzung 
der neuen Rolle, insbesondere die Frage, wie die Entwicklungspakete zu zerlegen sind 
und wie eine realistische Schätzung der Arbeitsaufwände erfolgen kann. 

17 | Exemplarisch sind hierzu die folgenden beiden Passagen: »Also die Mehrheit war 
der Meinung, dass wir mit Lean eine gute Sache machen. [...] Wir sollten es probieren, 
weil so, wie es vorher lief, hat es überhaupt keinen Spaß gemacht. Ja, dieser Dienst nach 
Vorschrift, wo einer ständig nur gesagt hat, was man zu programmieren hat, das hat 
keine Freude gemacht.« (C-42) »In den letzten Jahren hatten wir sehr starke Tendenzen, 
dass Vorgaben einfach von oben nach unten durchkommuniziert werden. Und ich den- 
ke, dass es zumindest ein kleiner Schritt ist, dass man in bestimmten Bereichen auch 
die Selbstständigkeit der Teams wieder ein bisschen stärkt. Also dort, wo die Teams 
auch Kernkompetenzen haben. [...] Aber in dem Bereich, wo die Entwicklungsteams 
Kernkompetenzen haben, sollte man die auch lassen. Und das, denke ich, wird durch 
den Lean-Ansatz einfach deutlich gestärkt wieder.« (C-46) 
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positiv konnotiert waren und bis heute sind. Soziologisch gewendet, ist es dem 
Unternehmen so gelungen, die »Künstlerkritik« (Boltanski/Chiapello 2003) der 
Entwickler aufzunehmen und für eine umfassende Neugestaltung ihres Ent- 
wicklungsmodells zu inkorporieren. 


3.3.2.2 Zentrale Merkmale des neuen Entwicklungsmodells 
In der Praxis lassen sich drei zentrale Säulen des neuen Entwicklungsmodells 
identifizieren: 

Zum ersten wird die Entwicklungsarbeit der Teams im Unternehmen nun 
als Teil einer synchronisierten und getakteten Wertschöpfungskette organi- 
siert. Die Basis hierfür sind die mit Scrum verbundenen kurzzyklischen Entwick- 
lungsintervalle, die die vormaligen langfristigen Projektzyklen ersetzen. Dies 
wird zur Grundlage für eine neue Stufe systemischer Integration. Je nach Be- 
reich wird dabei auf vier- oder sogar nur zweiwöchige Sprints gesetzt. Wo früher 
die Integration und der Test von Code erst sehr spät im Releasezyklus erfolg- 
ten, testet das Unternehmen nun die Kompatibilität bereits in einem sehr frü- 
hen Entwicklungsstadium. Das Zusammenspiel des Codes vieler verschiedener 
Teams wird nun kontinuierlich bzw. iterativ am Sprint-Ende geprüft. Die Basis 
bilden moderne Entwicklungsumgebungen, die hochautomatisierte und effizi- 
ente Test- und Integrationsverfahren erlauben. Organisatorische Voraussetzung 
hierfür ist, dass die Teams jeweils zum Taktende getestete Usable Software liefern. 
Das Prinzip der Usable Software wird so zu einem neuen Integrationsmodus und 
erlaubt es dem Unternehmen, die Schnittstellen neu aufeinander abzustimmen 
und die Teams in eine systemische Beziehung zueinander zu bringen (siehe dazu 
auch 3.3.3.1)."° 

Zum zweiten können mit der Zerlegung komplexer Software auf Basis 
von Backlogs nun auch große Entwicklungsvorhaben im Unternehmen arbeits- 
teilig organisiert werden - ohne dabei den Prozess der Spezifikation und Archi- 
tektur der Software systematisch und zeitlich von der Codierung zu trennen. 
Auf Basis einer Beschreibung der notwendigen Funktionalitäten der Software 
entsteht ein Backlog von Items, der kaskadenförmig heruntergebrochen und 
von den Product Ownern jeweils gegenüber dem zuständigen Team verantwortet 
wird. Da üblicherweise im Unternehmen mehrere Teams an einem Projekt bzw. 
Produkt arbeiten, wurde eine eigenständige pyramidenförmige Struktur von 
Product Ownern etabliert, die nach dem Prinzip Scrum of Scrums die Zusammen- 


18 | Ähnlich wie in der Fließfertigung entsteht so eine technisch, aber auch sozial or- 
ganisierte Infrastruktur, die verschiedene Teams in einen systemischen, an Flussprinzi- 
pien orientierten Zusammenhang zueinander bringt. 
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arbeit organisieren. Die Priorisierung und genaue Beschreibung der einzelnen 
Items erfolgt iterativ von Sprint zu Sprint. Diese neue Form der Strukturierung 
führt schließlich auch zu einer neuartigen Transparenz (siehe dazu auch 3.3.3.2). 
In einzelnen Bereichen wurde diese Transparenz auch für erweiterte Möglich- 
keiten bezüglich Reporting und Kontrolle genutzt. Während die Entwicklungs- 
arbeit früher für Außenstehende oftmals eine »Black Box« blieb, lässt sich nun 
am Ende jedes Sprints vergleichsweise einfach erkennen, welche Items des Back- 
logs erfolgreich abgeschlossen werden konnten und wie damit insgesamt der Sta- 
tus eines Projekts zu bewerten ist. 

Zum dritten wird schließlich das empowered team zum Nukleus des neuen 
Entwicklungsmodells. Grundbaustein der Entwicklungsorganisation ist damit 
nicht mehr der einzelne Software-Entwickler, sondern ein Kollektiv von Soft- 
ware-Entwicklern. Als autonome Einheit organisiert sich das Team-often selbst 
und verfügt in der täglichen Arbeit über hohe Gestaltungsspielräume. Auf Basis 
der Scrum-Prinzipien kann es selbst entscheiden, wie die Anwendungen pro- 
grammiert werden und welchen Workload sich das Team innerhalb eines Sprints 
vornimmt. Gleichzeitig gilt, dass das Team im Sinne des Empowerments wäh- 
rend des Sprints nicht durch Management-Interventionen von außen »gestört« 
werden darf. In der Praxis zeigt sich jedoch, dass sich die Bereiche hinsichtlich 
des Empowerments mitunter erheblich unterscheiden. In einem Bereich der 
Entwicklung werden z.B. 60 Prozent des Backlogs als »must« durch den Product 
Owner festgelegt, lediglich über die restlichen 40 Prozent kann das Team bei 
seiner Kapazitätsplanung noch wirklich entscheiden (siehe dazu auch 3.3.3.3). 

Mit der neuen Bedeutung des Teams vollzieht sich dabei auch ein Paradig- 
menwechsel weg vom Prinzip der individuellen Expertise hin zu kollektiven 
Wissensdomänen. So sind die Teamstrukturen und Arbeitsabläufe davon ge- 
prägt, Wissen innerhalb des Teams zu teilen und Transparenz zu schaffen. Im 
Kontrast zu anderen Fallunternehmen wird deshalb darauf gesetzt, dass alle 
Teammitglieder an einem Standort konzentriert sind. Vor diesem Hintergrund 
werden auch neue Meeting-Routinen, z.B. die Daily Scrums, flächendeckend 
etabliert. Sie werden für den kontinuierlichen Austausch von Wissen und für 
Lernprozesse im Team genutzt. Bei der konkreten Umsetzung gibt es jedoch 
zwischen den Bereichen deutliche Unterschiede. Während z.B. im Bereich der 
Kernentwicklung auch die Retrospektiven - die am Ende des Sprints zur Refle- 
xion und Verbesserung der Abläufe im Team dienen - von vielen Teams erfolg- 
reich genutzt werden, haben diese in der Anwendungsentwicklung eine weitaus 
geringere Bedeutung und Verbreitung. 


90 


Lean und agile Methoden in der Praxis 


3.3.3 Das neue Entwicklungsmodell in der Praxis 


Mit der Einführung von Lean verändert sich der Arbeitsalltag in den Ent- 
wicklungsabteilungen des Unternehmens grundlegend. Im Folgenden gilt es, 
diesen Wandel von Arbeit zu rekonstruieren und empirisch aufzuzeigen, wie 
die Entwickler selbst diesen Wandel erleben. Im Fokus stehen in den folgen- 
den Abschnitten: die Taktung und systemische Integration von Arbeit; die neue 
Transparenz und »Öffentlichkeit« in der Entwicklung; die Frage nach dem Em- 
powerment der Teams; schließlich die Folgen für die Belastungssituation der 
Beschäftigten. 


3.3.3.1 Taktung und systemische Integration in der Entwicklung 

Zentrales Prinzip des neuen Entwicklungsmodells ist die synchrone Taktung 
der Entwicklungsorganisation. Die Entwicklerteams produzieren in jedem 
Sprint nun Usable Software. In der Folge verändert sich der Rhythmus in der 
Arbeit erheblich. Nicht mehr langfristige Releasezyklen bestimmen den Arbeits- 
rhythmus, sondern - je nach Bereich - zwei- bzw. vierwöchige Takte. Für die 
Beschäftigten bedeutet dies auf der einen Seite, dass die früher am Release-Ende 
typischen Belastungsspitzen nun deutlich weniger geworden sind. Auf der ande- 
ren Seite sind durch die Taktung neue Herausforderungen entstanden. Entschei- 
dend dabei ist, dass die synchrone Taktung der Entwicklungsorganisation dazu 
führt, dass zeitliche Puffer in der Arbeit verloren gehen: Typische Hindernisse 
und Probleme im Projektverlauf können sich nun nicht mehr über eine lan- 
ge Laufzeit »verschmieren«. Die Unwägbarkeiten in der Software-Entwicklung 
können in den Teams schlechter kompensiert werden. Nicht selten ist dann aus 
der Perspektive der Beschäftigten steigender Arbeitsdruck die Folge. Sehr zuge- 
spitzt argumentiert ein Entwickler: 


»Einfach dieser Zyklus, dass man halt diese Taktung hat, diese Vier-Wochen-Taktung. 
Und das ist das, wo ich finde, das bricht uns gerade ein bisschen das Genick. Und das 
macht auch den Stress.« (C-49) 


Der Verlust zeitlicher Puffer gewinnt in der Praxis insbesondere deshalb an Be- 
deutung, weil mit der Einführung von Lean die Interdependenzen zwischen den 
einzelnen Teams gestiegen sind. Die Teams arbeiten weniger isoliert als in ihren 
vormaligen »Silos«. Vor dem Hintergrund der angestrebten Synchronizität der 
Gesamtorganisation — schließlich soll am Ende eines jeden Takts benutzbare 
und integrierte Software stehen - befinden sie sich in einem sehr engmaschi- 
ges Netz wechselseitiger Abhängigkeiten. Dabei ist letztlich entscheidend, dass 
tatsächlich alle Bereiche der Organisation im gleichen Takt schwingen, sonst 
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besteht die Gefahr, dass einzelne Funktionsbereiche oder Projekte den Rest der 
Organisation blockieren. Ein Gesprächspartner vergleicht deshalb die Organisa- 
tion mit einem »Uhrwerk«, in dem nun alle »Zahnräder genau ineinandergrei- 
fen« (C-48) müssen - anderenfalls steht das gesamte Uhrwerk still. 

Die innerorganisationalen Interdependenzen sind nun nicht mehr nur am 
Ende eines Releases spürbar, sondern prägen durch die Taktung und die damit 
verbundenen kurzen Entwicklungszyklen die Arbeit in vielen Teams. Ähnlich 
einer Just-in-time-Produktion führen ausbleibende Lieferungen oder ungeklärte 
Schnittstellen auch in der Entwicklung viel unmittelbarer und schneller zur Es- 
kalation, da nun nicht mehr ein mehrmonatiger Zeitraum bleibt, um entspre- 
chende Absprachen zu treffen, sondern in der Regel nur wenige Wochen oder 
sogar Tage. Letztlich gehen damit im »Uhrwerk« die Flexibilitätspuffer verloren. 

Hoher Abstimmungsbedarf, der in der Praxis als sehr zeitintensiv erlebt wird, 
bestimmt daher in vielen Teams den Arbeitsalltag. Besonders betroffen sind 
Product Owner sowie Architekten. Verzögerungen in einzelnen Teams können 
schnell Breitenwirkung entfalten und die Arbeit in anderen Teams blockieren, 
bei denen sich dann Zeitdruck und Frustration einstellt - schließlich können 
die wartenden Teams oftmals mit Blick auf die inhaltlichen Abhängigkeiten an- 
dere Themen bzw. Aufgaben nicht einfach vorziehen. In diesem engmaschigen 
Netz können aber nicht nur Verzögerungen oder ausbleibende (Management-) 
Entscheidungen zu Belastungssituationen führen, sondern auch Modifikationen 
durch einzelne Teams - z.B. in Bezug auf die Architektur oder den Code - kön- 
nen andere Teams unter großen Druck setzen. Schließlich müssen die Teams 
dann auf die Veränderungen unter hohem Zeitdruck reagieren. 

Wegen der gestiegenen Interdependenzen müssen die einzelnen Entwickler 
und die Teams die souveräne Kontrolle über ihre Zeitplanung aufgeben. Die 
Entwickler wissen, dass andere Teams auf ihre Zulieferung warten und bei nicht 
rechtzeitiger Lieferung blockiert sind. Mit Blick auf die Taktung wird der Um- 
gang mit normalen Unwägbarkeiten der Software-Entwicklung in der Praxis für 
viele Beschäftigte schwieriger als früher. Bereits eine ungenaue Planung, unein- 
deutige Architekturen oder eine Veränderung der funktionalen Anforderungen 
können nun in der Praxis zu großem Zeitdruck führen. 

Unsere Untersuchungen zeigen, dass unter dem Eindruck der Taktung ins- 
besondere ungeplante Zusatzaufgaben immer wieder zu Störungen des Ge- 
samtsystems führen können. Solche zusätzlichen Aufgaben bewirken, dass die 
Beschäftigten ihre selbst gesteckten Ziele nicht erfüllen können. Dies betrifft 
insbesondere Tätigkeiten im Kundensupport. Obwohl hierfür in vielen Teams 
im Fallunternehmen bei der Sprint-Planung gezielt Zeiten vorgesehen werden, 
beschreiben die Beschäftigten Support-Tätigkeiten als schwer zu steuernde 
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Unterbrechungen des Takts. In den Gesprächen mit Entwicklern finden sich 
häufig Passagen, die den damit verbundenen Druck und die Unzufriedenheit 
mit dem Nicht-Erreichen des eigenen Arbeitsziels plastisch nachvollziehbar ma- 
chen. Ein Entwickler würdigt zwar, 


»dass sich der Arbeitsablauf geändert hat. Das ist irgendwie teilweise motivierender, 
dadurch, dass man am Anfang eben die Tasks für die nächsten Tage plant und sich 
dann auch dransetzt und die so abarbeitet. Man ist ein bisschen zielgerichteter, organi- 
sierter. Auf der anderen Seite ist es durch die hohe Supportlast, die wir haben, teilweise 
dann einfach stressig, weil man das einfach überhaupt nicht planen kann. Und das 
führt dann auch teilweise zu Frustrationen, wenn man sieht, man würde gerne jetzt an 
diesem Feature arbeiten und ist gerade konzentriert bei der Arbeit - und jetzt kommt 
irgendwas dazwischen, was einen total rauswirft. Und verbringt die nächsten zwei Tage 
damit, irgendein Bugfix zu machen. Das ist frustrierend und nicht wirklich efhizient. 
Das führt auch zu Stress.« (C-37) 


Insgesamt ist die Frage nach den Folgen der Taktung und der systemischen In- 
tegration für die Beschäftigten in ihrer Komplexität nicht zu unterschätzen. 
Dahinter verbergen sich grundlegende konzeptionelle Herausforderungen der 
neuen Lean-Konzepte. Letztlich geht es um die Frage, wie sich eine Organisa- 
tion, die auch in hochqualifizierten Arbeitsbereichen in einem kurzzyklischen 
Takt schwingt und auf einem engmaschigen Netz von Interdependenzen ba- 
siert, systemisch und nachhaltig integrieren lässt. Insbesondere die mit der Lean- 
Diskussion verbundene Unterscheidung von »waste« und »slack« (Cyert/March 
1963) kann hier wichtige Anknüpfungspunkte bieten. Während »waste« für in- 
effiziente und nicht notwendige Organisationsbestandteile, -routinen und -pro- 
zesse steht, beschreibt »slack« die notwendigen sozialen und organisatorischen 
Puffer in einer Organisation und ihren Prozessen, die die einzelnen Abläufe in 
der Praxis anschlussfähig und kompatibel machen. 


3.3.3.2 Neue Transparenz: Die Software-Entwicklung wird öffentlich 

Mit der Einführung von Lean ist im Fallunternehmen in den Teams und der 
gesamten Entwicklungsorganisation eine neue Qualität von Transparenz ent- 
standen. Im Zuge der neuen Formen der Zusammenarbeit und des gestiege- 
nen Stellenwerts von Teamarbeit wird der Beitrag jedes Einzelnen nun stärker 
sichtbar als früher. Dies gilt nicht nur für die anderen Teammitglieder, son- 
dern - zumindest potenziell - auch für die Vorgesetzten und das Management. 
Diese neue Sichtbarkeit wird durch entsprechende Tools und Meeting-Rou- 
tinen unterfüttert bzw. institutionell verankert. Zentrale Stichworte sind in 
diesem Zusammenhang beispielsweise das Daily Scrum oder auch der Burn- 
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down-Chart'”, durch den der Fortschritt des Teams dokumentiert wird. Insge- 
samt verliert die Arbeit der Entwickler damit mehr und mehr ihren Charakter 
als »Black Box«. 

Die neue Transparenz hat in der Praxis zwei Seiten. Sie ist auf der einen Seite 
die Voraussetzung für echte Teamarbeit und ein damit verbundenes Empower- 
ment der Teams. Auf der anderen Seite kann sie aber auch im Sinne eines Kon- 
trollinstruments von den Beschäftigten als Bedrohung mit hohem Belastungs- 
potenzial erfahren werden. Diese beiden Seiten werden in der folgenden Passage 
sehr anschaulich geschildert: 


»Es gibt ja den Daily Scrum; das heißt, die Gruppe weiß sehr, sehr gut, was der Beitrag 
des Einzelnen ist. In einem Projektleiter-Setup ist das eventuell nicht so. Der Projekt- 
leiter spricht mit einzelnen Leuten, gibt ihnen eine Aufgabe, und dann ist es für die 
anderen eigentlich nicht so transparent, ob der da jetzt viel und gut dran arbeitet oder 
nicht. Das ist beim Scrum ganz anders. Absolute Transparenz, weil das Team plant zu- 
sammen, das Team arbeitet zusammen, das Team präsentiert am Schluss zusammen, 
trifft sich täglich und gibt sich gegenseitig Report, was gerade gut läuft und schlecht, wo 
hänge ich, wo hab ich Probleme, wo bin ich weitergekommen - absolute Transparenz. 
[...] Es gibt Teams, die blühen dort auf und entwickeln da eine Dynamik, die ganz toll 
ist. Aber es kann durchaus Mitarbeiter geben, die sich mit so einem Setup nicht wohl- 
fühlen, [... die das] als Belastung, glaube ich, empfinden. [...] Das kann dann leicht in 
eine Rechtfertigung - das hängt sehr von der Teamstimmung ab, ob das zur Rechtfer- 
tigung wird. Und dann ist es belastend, automatisch. Rechtfertigung ist immer belas- 
tend. [...] Ich erlebe es im positiven Sinn, jetzt gerade in dem Team, die sind super - da 
wird viel gelacht. Und auch wenn einer sagt, okay, ich bin da total hängengeblieben 
und jetzt habe ich es dreimal installiert; hat immer noch nicht geklappt - und dann 
lacht die ganze Gruppe, und hin und her; wird irgendein Scherz gemacht. Und dann 
eben sagt einer: Hey, lass mal, vielleicht kann ich dir helfen, oder so. Ja? Dann geht es 
so. Das geht nicht um Rechtfertigung, sondern tatsächlich um einen Austausch. Aber 
das hängt sehr von einzelnen Teams ab, wie die funktionieren.« (C-36) 


Wie diese Passage zeigt, hängt es insbesondere von der »Teamstimmung« ab, 
welche Wirkung die »absolute Transparenz« entfaltet. Wir haben in unseren 
Untersuchungen zahlreiche Teams angetroffen, die den hier skizzierten neuen 
Stellenwert der Teamarbeit als Verbesserung empfinden. In solchen funktionie- 
renden Teams berichten die Beschäftigten vom »Spaß«, den sie in der Arbeit 
haben, und davon, dass das Team für sie eine wichtige Ressource darstellt. Diese 


19 | Im Burndown-Chart wird der Anteil der in einem Sprint bereits erfolgreich abge- 
schlossenen Tasks an allen Tasks dokumentiert, für die das Team insgesamt die Ver- 
antwortung trägt. 
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Teams, in denen die Binnenbeziehungen oft über längere Jahre gewachsen sind, 
sind geprägt von einer Kultur wechselseitiger Unterstützung. Insbesondere ein 
solidarischer Umgang mit dem Arbeitsdruck und den hohen Anforderungen 
hilft den einzelnen Teammitgliedern. Statt individueller Profilierung bestimmt 
»Teamgeist« nach innen und außen das Klima. Die folgende Passage zeigt, dass 
diese kollegiale, vertrauensbasierte Kultur und die neuen Entwicklungsformen 
in einem sehr produktiven Verhältnis zueinander stehen können: 


»Es gibt ein Scrum-Team, von dem ich gehört hab, die haben sich sogar jetzt als Team 
einen Bonusplan, also Bonusziele, legen lassen. Die haben gar keine individuellen Ziele 
mehr. Die haben das mit dem Manager abgesprochen, haben gesagt, wir wollen als 
Team Bonusziele, wir wollen keine individuellen mehr, und hat das abgesegnet, und 
das funktioniert. Das ist irgendwie - ja, schön, man arbeitet ja sowieso den ganzen Tag 
als Team. Wir arbeiten auch sehr oft im Pair-Programming-Modus, und da kann man 
auch schon wieder gar nicht mehr sagen, wer was gemacht hat oder wer wann wie viel 
Zeit gebraucht hat. [...] Insofern: was zählt, sind die Ergebnisse und nicht, wie man 
dazu gekommen ist.« (C-37) 


Die hier beschriebene Stärkung des »Teamgeists« ist jedoch nur die eine Seite der 
Medaille. Auf der anderen Seite finden sich im Unternehmen zahlreiche Teams, 
in denen im Zuge der Einführung von Lean die Konflikte deutlich zugenom- 
men haben und der innere Zusammenhalt im Team gefährdet ist. Exemplarisch 
lässt sich dies an den folgenden beiden Interviewabschnitten nachvollziehen: 


»Was sich auch verändert hat: dass ich deutlich teamzentrierter arbeite und darüber 
auch deutlich mehr Teamprobleme mit bewältigen muss. Konflikttmanagement ist ein 
Riesenthema, da wird man ein bisschen reingestoßen, ohne dafür überhaupt Werkzeu- 
ge zu bekommen. Dadurch, dass das Team bestimmt, wie es funktioniert, prallen halt 
auch sehr harte Meinungen aufeinander, weil nicht mehr jeder Entwickler da sitzt und 
vor sich hinentwickelt, sondern weil das Coding jetzt halt mehreren gehört. Das hat 
sich, das hat sich deutlich verändert.« (C-58) 


»Ich würde sagen, es verstärkt die Konflikte, die es gibt. Weil dadurch, dass es wie in 
einem Kessel alles ist; und nach außen ist es eigentlich nicht erwünscht, dass irgend- 
welche Probleme nach außen treten, sondern die sollten im Team gelöst werden. Das 
kann sich, glaube ich, unglaublich hochschaukeln. Weil wenn da ein sehr Ehrgeiziger 
sich unbedingt durchsetzen will und dabei die Grenzen zu den anderen Kollegen nicht 
wahrt, dann kann es sehr schnell zu Konflikten kommen. Also das habe ich erlebt in 
dem einen Projekt. Und ich denke, es ist sehr wichtig, dass jeder sein Gesicht wahren 
kann und dass jeder respektiert wird als Person, unabhängig davon, wie viel von den 
Backlog-Items er jetzt erledigt hat oder nicht. Und ich glaube, es ist auch normal, dass 
ein Team Stärkere und Schwächere hat. Der eine istim Coding-Implementieren stärker, 
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der andere ist vielleicht sehr wichtig für das Team als solches, wirkt als ausgleichen- 
de Komponente, damit das Team überhaupt funktioniert. Und das kommt überhaupt 
nicht zum Tragen dann.« (C-42) 


In beiden Passagen wird deutlich, wie die Umsetzung von Lean die Beschäf- 
tigten zu einer deutlich intensiveren Interaktion und Zusammenarbeit zwingt. 
Man muss nun »teamzentrierter« arbeiten und kann nicht mehr als einzelner 
Entwickler »vor sich hinentwickeln«. Für den Einzelnen ist es nicht mehr mög- 
lich, sich in die angestammten »Hoheitsgebiete« (C-46) mit geregelten »Gren- 
zen« zurückzuziehen; man muss nun als Entwickler »häufiger die Komfortzone« 
(C-59) verlassen. Gerade die zweite Passage macht deutlich, dass dabei auch Leis- 
tungsunterschiede deutlicher als früher zutage treten. Der Einzelne wird mehr 
denn je »öffentlich«. Unter dem Druck des Takts können die so entstehenden 
Konflikte in den Teams schnell eine Eigendynamik gewinnen. Dann werden 
die Scrum-Teams zu einem »Kessel« und zu einer teamöffentlichen Arena von 
Auseinandersetzungen.” 

Insgesamt reicht es jedoch nicht aus, allein auf ein professionalisiertes Kon- 
fliktmanagement zu setzen. Vergleicht man die Teams genauer, stellt man fest, 
dass sich insbesondere Vertrauen als ein zentraler Erfolgsfaktor der Teams er- 
weist, die Lean und das neue Entwicklungsmodell im Sinne von Teamgeist und 
Empowerment vorantreiben. Ohne eine etablierte Vertrauenskultur hingegen 
wird die Grundidee der Transparenz in den Teams weniger als Chance zu ech- 
ter Kooperation und Unterstützung erfahren, sondern eher als Bedrohung und 
potenzielles Kontrollinstrument. Gerade erfahrene Entwickler fürchten in der 
Folge um ihren Expertenstatus und ihre individuellen Hoheitsgebiete. Insbeson- 
dere das Daily Scrum wird in diesem Fall kaum positiv angenommen - vielmehr 
bestimmen dann Kommentare wie »man muss sich rechtfertigen« oder »man 
muss sich offenbaren« die Szenerie: 


»Während der Arbeit hat man einfach mehr Druck. Weil du musst dich quasi jeden 
Tag im Daily Scrum rechtfertigen, mehr oder weniger, kann man so sehen. Was habe 
ich gemacht? Wo war mein Problem? Was mache ich heute? Das heißt, permanent ist 


20 | Zahlreiche Beispiele zeigen, dass die entstehende Konfliktdynamik in den Teams 
brisant werden kann, wie folgende Passage exemplarisch verdeutlicht: »Aber ich habe 
schon gerade das Gefühl, dass ich bei mir im Team so was wie einen stärkeren Mob- 
bing-Ansatz sehe. Weil es einfach natürlich immer jemanden gibt, der nicht so leis- 
tungsfähig ist im Team. Wenn man merkt: Okay, die ist halt vielleicht etwas langsamer 
oder kennt sich da nicht so gut aus oder sonst was; dann arbeitet man nicht so gerne 
mit der zusammen oder lernen wir nicht so gut ein, weil sie uns also in unserem Team 
nicht richtig weiterbringt.« (C-59) 
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man quasi unter Kontrolle, sage ich jetzt mal, und hat permanent diesen Druck, fertig 
werden zu müssen.« (C-44) 


»Es ist natürlich schon, also man legt ja morgens immer so einen Offenbarungseid 
dann ab in diesen Meetings, was hat man geschaft, was sind die Probleme? [...] Also 
man muss halt wirklich seinen Mitarbeitern oder seinen Kollegen dann auch vertrauen 
können, [...] zumindest in diesen Meetings auch einen respektvollen Umgang mitei- 
nander haben, dass man eben nicht Probleme oder Leute klein macht. Und wenn das 
anfängt, dann hält man halt Wahrheiten und Probleme und so weiter gleich wieder 
zurück.« (C-46) 


Diese Erfahrungen illustrieren, dass ohne Vertrauen ein offener, produktiver Er- 
fahrungsaustausch kaum möglich ist. »Wahrheiten und Probleme« werden dann 
»gleich wieder zurück[gehalten|«; in den Worten eines anderen Entwicklers: »Es 
lässt keiner das Schild runter.« (C-46) Gleichzeitig können ohne Vertrauen Mee- 
tings wie das Daily Scrum für die Beschäftigten schnell Teil einer Belastungssi- 
tuation werden, in der sie sich kontrolliert und unter Druck empfinden, weil sie 
sich »keine Blöße« (C-34) geben wollen. 

Die Notwendigkeit von Vertrauen beschränkt sich nicht auf die Binnenbe- 
ziehungen in den Teams. Auch die Vertrauensbeziehungen zum Management 
sind von großer Bedeutung. Die folgende Passage führt vor Augen, wie wichtig 
es für die Teams ist, darauf vertrauen zu können, dass Meetings oder Tools wie 
der Burndown-Chart nicht als Kontrollinstrumente verwendet werden: 


»Was ich wirklich weiß, oder was man ja spürt, ist, dass manchen eben dieses Trans- 
parente gar nicht in den Kram passt. Dass man sich da quasi jeden Tag hinstellen muss 
und sich quasi rechtf-, also man muss sich nicht rechtfertigen, aber es ist so ein, da steht 
dann halt dann der Product Owner auch mit drin. Das ist vielleicht bei uns auch nicht 
ganz gut, dass der Product Owner am Scrum-Meeting teilnimmt, soll er ja eigentlich 
nicht, aber der ist bei uns da und manchmal kommen auch ganz fremde Leute, so die 
Chefs oder so, und gucken mal [...] Oder auch das Review-Meeting alleine, da ist man 
ja schon unter Druck und muss irgendwie zeigen, was habe ich da eigentlich in zwei 
Wochen geliefert. So ein bisschen. Und das hatte man früher nicht in dem Maße, dass 
es da so ein öffentliches Review-Meeting gab. So dieses Transparente macht es, glaube 
ich, für manche, man kann sich nicht mehr so gut verstecken irgendwie. Also wenn da 
der Chef immer ins Review-Meeting kommt und man nie was zeigt, dann ist das schon 
schlecht. Dann hat man schon ein schlechtes Gefühl.« (C-72) 


Auch in anderen Interviews zeigt sich immer wieder unterschwellig, dass den 
Beschäftigten — obwohl sie zu ihren direkten Linien-Vorgesetzten und auch 
den Product Ownern zumeist sehr gute Vertrauensbeziehungen unterhalten - 
durchaus auch die Kontrollpotenziale von Lean bewusst sind. Vereinzelte sehr 
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zugespitzte bzw. zynische Bemerkungen wie »Entwicklerschlachttag« (als Be- 
zeichnung für das Review, C-58) zeigen die Sensibilität dieser Thematik in der 
Wahrnehmung der Entwickler. Überwiegt bei Einzelnen die Empfindung, kon- 
trolliert zu werden, kann es auch vorkommen, dass sie sich komplett einigeln: 


»Und ab diesem Zeitpunkt, was mich persönlich betrifft - ich weiß, die anderen haben 
das nicht so empfunden, aber was mich persönlich betrifft, ich empfand das sofort als 
Kontrollmechanismus, dass jeden Morgen jemand mich fragen musste, was ich gestern 
gemacht habe und was ich heute machen werde. Das war bei mir noch nie vorgekom- 
men. Also ich habe ja immer eine gute Arbeit geliefert, und alle wussten das. Und 
jetzt plötzlich stand ich da und musste jeden Tag irgendwie geradestehen und jemand 
berichten, was ich da gemacht habe und was ich machen werde. Das war, wie gesagt, 
rein vom Empfinden her, für mich eine unangenehme Situation. Bis jetzt habe ich mich 
auch damit nicht richtig abgefunden. Klar, ich habe dadurch, dass ich ja sowieso einen 
guten Job gemacht habe, habe ich da zu irgendwelchem Zeitpunkt gesagt: Ich habe 
nichts Neues zu berichten.« (C-45) 


Dieses Beispiel zeigt sehr anschaulich, wie Lean nur pro forma und nach außen 
umgesetzt wird, während ein individualistischer Expertenmodus weiter die 
konkrete Arbeit bestimmt. In der Praxis entstehen dann regelrechte Formen 
eines »potemkinschen Scrum« bzw. »potemkinschen Lean«, bei dem zwar die In- 
stitutionen scheinbar »nach Lehrbuch« umgesetzt werden, aber ohne die aktive 
Beteiligung der Beschäftigten nie wirklich mit Leben erfüllt werden. Die mit 
Lean verbundenen Potenziale - z.B. in Richtung Empowerment - können dann 
in der Praxis kaum zum Tragen gebracht werden. 


3.3.3.3 Empowerment — Möglichkeiten und Grenzen 

Ausgehend von den Überlegungen zu Scrum und den agilen Methoden bildet 
das Empowerment der Teams konzeptionell eine der zentralen Säulen des neuen 
Entwicklungsmodells im Unternehmen. In der Praxis zeigt sich, dass der Um- 
gang mit dem Empowerment variiert und die Beschäftigten nicht selten die Er- 
fahrung eines »gebremsten Empowerments« machen. 

Empowerment meint dabei zunächst einmal die Fähigkeit der Teams, ihre 
Arbeitsmenge eigenverantwortlich zu steuern. Grundsätzlich bestehen für die 
Teams sehr weitgehende Steuerungsmöglichkeiten, indem sie das Recht haben, 
sich ohne Mitsprache des Managements für bestimmte Positionen aus der An- 
forderungsliste für zuständig zu erklären - in der Fachsprache der Entwickler: 
Sie »committen« sich für »Backlog-Items«. Unsere Untersuchungen machen 
deutlich, dass dieser Mechanismus in den verschiedenen Bereichen unterschied- 
lich umgesetzt bzw. gelebt wird. Während das Empowerment in der Kernent- 
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wicklung vergleichsweise stringent gelebt wird, wird in anderen Entwicklungs- 
bereichen eine alternative Variante umgesetzt. Hier sind 60 Prozent des Backlogs 
zentral vorgegeben; dieses Aufgabenpaket ist in der Perspektive der Beschäf- 
tigten nicht verhandelbar, lediglich die verbleibenden 40 Prozent unterliegen 
einem eigenverantwortlichen Commitment der Teams. Ein Befragter beschreibt 
dies als eine »Haupteinschränkung von Scrum« (C-68). 

Eine zentrale Erfahrung der Beschäftigten in der Anwendungsentwicklung 
besteht darin, dass die Teams mit dem vorgegebenen Backlog, der eigentlich 
nur 60 Prozent ihrer Kapazität beanspruchen sollte, oftmals bereits ausgelastet 
sind. Dadurch verliert ein aktiver, vom Team eigenverantwortlich betriebener 
Prozess des Commitments an Bedeutung. Infolge der hohen Grundauslastung 
wird der selbstständigen Aufwandsschätzung durch das Team das Fundament 
entzogen; sie erscheint wie ein sinnfreies Ritual, das mit Empowerment oder 
einer eigenständigen teamzentrierten Arbeitsplanung nichts zu tun hat. In der 
konkreten Arbeitspraxis haben sich in diesen Fällen nicht selten Routinen eta- 
bliert, in denen der Product Owner - und nicht das Team - die Backlog-Items in 
Tasks zerlegt, ihren Aufwand (zumindest implizit) schätzt und einzelnen Team- 
mitgliedern zuweist. Damit geht ein zentraler Aspekt des Empowerments und 
der Selbstorganisation der Teams verloren. 

Die betroffenen Teams erleben sich dann in Bezug auf ihre Auslastung und 
ihren Workload als stark von außen gesteuert. Viele haben das Gefühl, dass von 
»oben« Aufgaben und Funktionalitäten »eingekippt« werden, die dann unter 
hohem Zeitdruck und immer wieder an der Grenze der eigenen Belastbarkeit 
bearbeitet werden müssen. Analog zu Prinzipien der Lean Production existiert 
zwar theoretisch die Möglichkeit, eine virtuelle Reißleine zu ziehen - in der 
Praxis erscheint es jedoch kaum vorstellbar, davon Gebrauch zu machen: »Man 
kann natürlich immer eine Reißleine ziehen, ich habe sie aber noch nirgends 
geschen bei uns. Also man kann es nicht wirklich. Da hängt viel zu viel dran bei 
uns noch, und, und ich glaube, also vor allem, ich weiß nicht, ob sich jemand 
trauen würde, die zu ziehen.« (C-66) 

Viele Befragte bemängeln zudem, dass die Teamplanung vom Management 
nicht immer respektiert wird. Ein Aspekt dieser Kritik besteht darin, dass die 
Teams nicht immer stabil und über einen längeren Zeitraum zusammenarbeiten 
können. Immer wieder werden - so wird berichtet - Teammitglieder auf Grund 
externer Prioritätensetzungen kurzfristig aus den Teams abgezogen. Auch um- 
gekehrt wird die kurzfristige Aufstockung von Teams nicht per se als Entlastung 
erlebt. Oftmals sind die Teams dann zwar numerisch verstärkt worden; um die 
neuen Teammitglieder wirklich produktiv zu machen, sind jedoch lange An- 
lernphasen notwendig, die zunächst Mehrarbeit bedeuten. Darüber hinaus wird 
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immer wieder davon berichtet, dass Vorgesetzte in die Sprints intervenieren oder 
die Arbeit der Teams kontrollieren wollen. Dies wird von den Befragten als Ein- 
griff in die Sphäre des Teams bzw. Einschränkung des Empowerments des Teams 
kritisiert. 

Vor allem aber bemängeln die Beschäftigten eine zunehmende inhaltliche 
Verengung ihrer Tätigkeiten. Sie vermissen das Gefühl, in die mittel- und lang- 
fristigen Planungen des Unternehmens bzw. ihrer Bereiche eingebunden zu 
sein. Ein Befragter beschreibt dies sehr zugespitzt: »Also wir leben praktisch 
von der Hand in den Mund. Von Sprint zu Sprint.« (C-55) Dabei geht es den Be- 
schäftigten nicht nur um Mitspracherechte, sondern oftmals wissen sie einfach 
nicht, in welche Richtung sich ihr Bereich inhaltlich über den nächsten Sprint 
hinaus bewegt. Neben der fehlenden Einbindung in grundlegende inhaltliche 
Planungsfragen wird auch der mangelnde Kontakt zum Kunden kritisiert. Ins- 
gesamt befürchten die Entwickler, dass ihre Arbeit »monotoner« und weniger 
»kreativ« wird, aber auch dass die »individuelle Handschrift« (C-66) verloren 
geht, ja dass die Arbeit zunehmend ihren ganzheitlichen Charakter verliert. Die 
folgenden Passagen illustrieren dies: 


Ein heutiger Entwickler »macht da halt in der Regel nur einen kleinen Bereich und 
tut sich schwer, das in das Ganze, in das Große einzuordnen - und früher, klassische 
Entwicklung war halt alles. Also man hat wirklich zu Beginn mit dem Solution Ma- 
nagement eine Spezifikation gemacht, hat sich überlegt, also man hat ein bisschen 
Portfolio Planning gemacht, war man mit beteiligt, man hat Spezifikationen für ein 
Thema gemacht, man hat das Design für das Thema gemacht, man hat Rohversionen 
für die Doku bereitgestellt, man hat das Thema teilweise sogar geschult, man war in 
Kundenprojekten vor Ort, wo man das Thema mal beim Kunden irgendwo eingeführt 
hat. Also dieser Facettenreichtum, das ist halt völlig verloren. Also das ist, wenn man 
das kennt, die Vielfalt, die es früher gab, das war eine andere. Also ist heute nicht mehr 
gegeben. [...] Man ist so weit vom Kunden weg [...] Wenn man dieses Modell jetzt lang- 
fristig fahren muss, ich glaube, da wird’s dann doch relativ monoton irgendwo. Man 
macht zwar immer wieder neue Themen, aber man macht’s nicht End-to-End.« (C-67) 


»Also manchmal fühlt sich das Team schon zu wenig involviert in die Gesamtplanung 
[...], und unten am Team kommt dann im Prinzip so ein quasi fertig geplanter Batzen 
an. Und es ist schon die Gefahr jetzt, dass man so ein bissel aus dem Kontext raus- 
kommt. [...] Man hat zwar jetzt ein konkretes Päckchen, aber man weiß oft nicht, wie 
das im Kontext hängt.« (C-66) 


In diesen und in vielen anderen Äußerungen der Entwickler wird deutlich, 
dass sie insbesondere einen ganzheitlich geschnittenen Arbeitsgegenstand ver- 
missen, den man »End-to-End« betreuen kann. Ein Teil der Beschäftigten erlebt 


100 


Lean und agile Methoden in der Praxis 


die Veränderungen durch das neue Entwicklungsmodell nicht als Empower- 
ment der Personen und Teams, sondern als eine schleichende Verschlechterung 
ihrer Arbeitssituation. Im Zentrum steht dabei das Gefühl, nur »ausführendes 
Organ« zu sein; man sieht sich in einer Situation des Ausgeliefertseins gegenüber 
einem »vorgefertigten Backlog, wo sich schon alles, wo sich schon jemand was 
ausgedacht hat komplett, den Leuten gegeben wird und es wird eigentlich nur 
noch abgearbeitet« (C-32). 

Die Kritik an einem mangelnden Empowerment wird in der Praxis interes- 
santerweise immer wieder mit dem Thema Industrialisierung verknüpft. Dabei 
kommt eine unterschwellige Angst zum Ausdruck, »wie am Fließband« zu arbei- 
ten. Ein Entwickler argumentiert: »Ich hab das Gefühl, man versucht, generell, 
mit Scrum versucht man Fließband-Produktion einzuführen, aber wir machen 
keine Fließbandproduktion. Wir machen Software-Entwicklung.« (C-50) In 
unseren Erhebungen sind wir immer wieder auf ähnliche Argumentationsmus- 
ter gestoßen, die die Perspektive der Beschäftigten sehr anschaulich zum Aus- 
druck bringen: 


»Also jetzt gehen wir mal von der Anerkennung her: [...] dass ich jetzt als Entwickler, 
der jetzt vielleicht nicht so nach außen geht, mich mehr wertgeschätzt fühle, würde ich 
sagen: Nein. [...] Es wird einfach mehr so Arbeitsabläufe geben, die eigentlich vorgege- 
ben sind, also weniger Kreativität. Mehr sich an Schemata und Regeln halten, auf Zeit 
arbeiten, in Rastern arbeiten.« (C-57) 


»Am Anfang hatte man extreme Zweifel, also oder ich persönlich extreme Zweifel, weil 
man dachte, wie soll das funktionieren? Man hat immer nur gesehen: Na ja, das ist ein 
Modell aus der Produktion, so Fließbandmodell, man macht wirklich ja Produktion 
und man optimiert irgendwelche Produktionsprozesse. Wie soll denn das mit kreativer 
Arbeit zusammenspielen? Da war ich also absolut skeptisch am Anfang. [...] Da leanifi- 
ziert man jetzt ’ne Produktion, man nimmt irgendwelche Handgriffe weg oder so. Wir 
machen nicht immer dieselben Handgriffe. Das ist das Problem.« (C-66) 


»Ich glaube, die Entwicklungszyklen werden viel kürzer werden. Die Stressbelastung 
wird steigen. Die Leute werden sich wahrscheinlich spezialisieren auf ganz enge Be- 
reiche, was sie gut können. Und es wird wahrscheinlich eine Industrialisierung der 
Entwicklung stattfinden in dem Sinne, dass der Softwareprozess wie ein Autoherstel- 
lungsprozess aussehen wird. [...] Weil wie gesagt, das Produkt steht im Mittelpunkt. 
Das ist in Ordnung. Aber der Mensch bleibt außen vor. Das ist für mich ein Zeichen 
der Industrialisierung.« (C-42) 


Diese Passagen deuten darauf hin, dass sich hinter der Kritik der Mitarbeiter 
an der Industrialisierung auch ein Gefühl mangelnder Wertschätzung und An- 
erkennung ihrer Expertise verbirgt. Die Beschäftigten erleben es gewissermaßen 
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als einen Affront, dass ihre Arbeit entlang industrieller Prinzipien (insbesondere 
in Anlehnung an die Automobilindustrie) organisiert wird. Dies stellt nicht nur 
ihre berufliche und professionelle Identität in Frage, sondern wird vor allem 
dem komplexen und kreativen Charakter ihrer Arbeit nicht gerecht. Fragen wie 
»Sind wir Fließbandarbeiter?« (C-42) bringen die damit verbundene Empörung 
zum Ausdruck. 


3.3.3.4 Folgen für die Belastungssituation 

Schon vor der Einführung von Lean war die Arbeit in den Entwicklungsberei- 
chen in den letzten Jahren durch ein hohes Stressempfinden und ein zunehmen- 
des Belastungsniveau gekennzeichnet. Vor diesem Hintergrund erhoffte man 
sich, mit der Reorganisation der Entwicklung eine Verbesserung der Situation 
zu erreichen. Lean und die damit verbundene flächendeckende Anwendung 
agiler Methoden erschienen als ein wichtiger und potenziell wirkungsvoller 
Hebel, um den Belastungslevel in den Entwicklungsbereichen zu senken. Die 
selbstständige Schätzung des Arbeitsaufwands durch die Teams beispielsweise 
wurde als geeignetes Instrument betrachtet, um ein nachhaltiges Arbeitstempo 
in Software-Projekten zu realisieren. Gleichzeitig nahm man an, die Idee des 
Empowerments, die Stärkung von Teamarbeit oder auch das Konzept der kon- 
tinuierlichen Verbesserung biete Potenzial, die Sinnstrukturen bzw. den »Kohä- 
renzsinn« (Antonovsky 1979) der Beschäftigten zu stärken und dadurch nicht 
nur Belastungen abzubauen, sondern insbesondere auch salutogene Ressourcen 
zu erschließen. 

In unseren Untersuchungen zeigt sich jedoch, dass mit der Einführung des 
neuen Entwicklungsmodells diese salutogenen Potenziale nur eingeschränkt 
bzw. nur in wenigen Bereichen Wirkung entfalten konnten und dass die Belas- 
tungen für die Beschäftigten insgesamt gestiegen sind. Exemplarisch argumen- 
tiert ein Befragter: »Die Intensität ist noch mal eine andere geworden.« (C-59) 
Die kurzen Entwicklungszyklen und die systemische Integration der Organisa- 
tion führen dazu, dass ohne organisatorischen »slack« zeitliche und organisato- 
rische Puffer - ganz im Sinne einer Lean Production - verloren gehen (vgl. dazu 
bereits Stachle 1991). Man arbeitet nun »verbissener« und »angestrengter« (C-57), 
und zudem gibt es zwischen den Takten, aber auch zwischen den Releases kaum 
noch Erholungspausen. Unter dem Eindruck der Taktung entsteht dann bei vie- 
len das Gefühl »permanenten Zeitdrucks« und von »Dauerstress«. Exemplarisch 
stehen dafür die folgenden Passagen: 


»Zentrale Belastungen? Ich denke man hat so eine Art Dauerstress. Ja, dadurch, dass 
man immer in diesem Vier-Wochen-Rhythmus lebt. Also der Stresslevel wird perma- 
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nent auf einer Ebene gehalten, man hat nicht diese Kurven, sondern man hat halt diese 
durchgehende gleiche Belastung.« (C-50) 


»Aufgrund der Requirements, die auf uns einprasseln, wird der Druck unveränderlich 
hoch bleiben [...] Für Frust sorgen tut es vielleicht gar nicht so unbedingt, man ge- 
wöhnt sich an den Druck. Die Frage ist, wie lange hält man das aus, auch gesund- 
heitlich? Das ist die nächste Frage. Wir arbeiten jetzt schon seit zwei Jahren in diesem 
Modus unter sehr hohem permanentem Druck und es ist die Frage, was bedeutet das 
gesundheitlich, wenn man das über einen größeren Zeitraum macht? (C-62) 


»Aber die Tendenz [...] ist, dass man wohl gerne die Taktung, die Schlagzahl erhöhen 
möchte. Ich meine, der Ausdruck Sprint ist ja wohl selbstredend. Ja, wir entwickeln 
nicht mehr, sondern wir machen Entwicklungssprints, ja. Die Frage ist, ob eine Tak- 
tung, die immer schneller sein wird, machbar ist von jemand, der immer älter wird? 
[...] Idealerweise müsste es ja so sein, dass es nicht automatisch bedeutet, dass jeder 
immer mehr arbeiten muss, wenn man die Effizienz erhöht. Ideal wäre es ja, wenn man 
die Effizienz erhöht und sagt, trotzdem können wir schneller produzieren. Das wäre 
ja genial. Nur die Organisation zieht da nicht mit. Das bedeutet, schneller bedeutet 
immer auch mehr Belastung. Und das ist die Frage, wie weit geht das? Bis wohin? Ab 
wann, ab wann geht es nicht mehr? Keine Ahnung.« (C-65) 


Die grundlegende Veränderung der Belastungssituation, die sich hier andeutet, 
vollzieht sich praktisch allerdings nicht in allen Teams in gleicher Weise. Unsere 
empirischen Ergebnisse legen es nahe, zwei idealtypische Szenarien zu unter- 
scheiden. 

Szenario 1: Lean ohne Empowerment. In diesem Szenario werden vie- 
le Prinzipien von Lean nur rudimentär bzw. pro forma umgesetzt - ohne ein 
grundsätzliches Empowerment der Teams. Oftmals wird lediglich unter einem 
neuen Titel weiter gearbeitet wie bisher. Ein individualistischer Expertenmo- 
dus bestimmt weiterhin die Arbeitspraxis. Zentrale Elemente wie die Schätzung 
der Arbeitsaufwände in einem kollektiven Entscheidungsprozesses oder die 
Zerlegung der Aufgaben in überschaubare Tasks erodieren, Meetings werden 
seltener abgehalten, übrig bleibt nicht selten ein »potemkinsches Scrum«, das 
Scrum-Prinzipien nur noch an der Oberfläche aufrecht erhält. Dadurch können 
neue Handlungsspielräume nicht erschlossen werden und bleiben Lernschleifen 
(z.B. im Sinne einer Verbreiterung von Wissen, einer realistischen Planung der 
Sprints, aber auch der Steuerung von Belastungen) blockiert. Letztlich bleibt den 
Teams aufgrund dieser Blockierung ein qualitativer Sprung in Richtung Em- 
powerment versperrt. 

Eine maßgebliche strukturelle Ursache für die Entstehung solcher »potem- 
kinscher Scrums« ist - auf der einen Seite - dann gegeben, wenn die Teams ihre 
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Arbeitsmenge nicht wirklich eigenverantwortlich steuern können. Das Schätzen 
der Arbeitsaufwände wird für die Beschäftigten dann zu einem inhaltsleeren, 
weil folgenlosen Ritual, das unter dem Druck des Arbeitsalltags schnell aufge- 
geben wird. Im Sinne eines Domino-Effekts verlieren dann auch andere Ziele 
der neuen Methoden - z.B. die Entwicklung und Verbreiterung des individu- 
ellen Erfahrungsschatzes - in der Praxis an Bedeutung. Auf der anderen Seite 
existiert eine subjektbezogene Ursachendimension, die mit den Stichwörtern 
Transparenz und Vertrauen verknüpft ist. Zumindest unterschwellig erleben 
nicht wenige Befragte im Unternehmen die mit Lean verbundene Transparenz 
als Bedrohung. Sie befürchten (potenziell) neue Möglichkeiten der Kontrolle 
und auch eine gestiegene Austauschbarkeit des einzelnen Entwicklers. Beschäf- 
tigte, die z.B. um ihren Status bzw. sogar um ihren Arbeitsplatz fürchten oder 
Angst vor Kontrolle haben, werden kaum zu engagierten Protagonisten von 
Lean werden. 

Mit Blick auf die Belastungen bedeutet dies, dass sich die salutogenen 
Potenziale des neuen Entwicklungsmodells nicht ausreichend entfalten kön- 
nen. Gleichzeitig stehen die Beschäftigten nun jedoch unter dem Druck der 
Taktung - die nicht mehr hintergangen werden kann und gewissermaßen zum 
zentralen Merkmal des »potemkinschen Scrum« wird. Vor dem Hintergrund 
eines kaum ausgeprägten Empowerments sehen sich die Beschäftigten dem Takt 
wehrlos bzw. ohne Korrektiv ausgeliefert. Die Teams erleben sich dann als von 
außen getrieben bzw. fremdbestimmt. Ohne ein gelebtes Empowerment kann 
keine teambasierte Steuerung der Arbeitsmenge und der Belastung bzw. kein 
gemeinsamer, kollegialer Ausgleich von Belastungsspitzen erfolgen. Die zentrale 
Gefahr im Szenario »Lean ohne Empowerment« besteht folglich darin, dass für 
die Beschäftigten zusätzliche Belastungen entstehen, die nicht durch neue Res- 
sourcen abgefedert bzw. kompensiert werden können; dann drohen Aufschau- 
kelungseffekte der verschiedenen Wirkmechanismen, die zu einer gefährlichen 
Abwärtsspirale führen können. 

Szenario 2: Lean ohne Nachhaltigkeit. In diesen Teams besteht eine große 
intrinsische Motivation und Bereitschaft, Lean in der Arbeitspraxis konsequent 
umzusetzen; die Teams erleben sich nicht als von außen getrieben, sondern ent- 
wickeln eine sehr hohe Leistungsbereitschaft, weil sie das fokussierte Arbeiten 
unter den neuen Voraussetzungen als befriedigend empfinden. Kennzeichnend 
für dieses Szenario ist insbesondere eine positive und vertrauensbasierte Team- 
kultur, die von dem Gefühl geprägt ist, an einem Strang zu ziehen. Wenn un- 
erwartete Hindernisse oder Schwierigkeiten in der Entwicklung auftauchen 
oder vom Management zusätzliche Features in Auftrag gegeben werden, ver- 
suchen die Beschäftigten, dies mit eigenem Engagement zu kompensieren: »Wir 
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melden sechs Stunden zurück im Scrum, aber das sind keine sechs Stunden. Wir 
arbeiten dann halt länger. Wir rödeln halt.« (C-48) 

Eine solche Praxis steigert zwar kontinuierlich Effizienz und die Produktivi- 
tät - es besteht aber die Gefahr, dass mittelfristig die Nachhaltigkeit verloren 
geht und sich die Teams »selbst die Luft abdrehen«. Die Beschäftigten äußern 
dies mit Formulierungen wie »wir kommen nicht mehr zum Luftholen« oder 
»uns fehlen die Atempausen«. Einige beschreiben die Teams als »ausgelaugt« 
oder bemerken bereits nach wenigen Monaten eine gewisse »Ausbrennung«. 
Gleichzeitig klagen die Teams, dass sie zunehmend den Blick für das große Gan- 
ze verlören. Unter dem hohen Druck des Takts erscheint es vielen schwierig, 
kreativ zu Innovationen der Produkte beizutragen. Sie befürchten, in diesem 
Prozess zunehmend die Kompetenz als Team zu verlieren, auch über die Rich- 
tung mitzubestimmen, in die sich die Anwendungen entwickeln sollen. 

Eine eindimensionale Produktivitätssteigerung kann so mittelfristig zu 
einer Zunahme der Belastungen für die Beschäftigten führen. Indem sie unter 
dem Druck der Taktung und mit Blick auf die »committeten« Ziele fehlenden 
»slack« in der Organisation durch eigenes Engagement kompensieren, wächst 
die Gefahr, sich dabei systematisch zu überfordern. Das Empowerment ist - wie 
sich in der Praxis zeigt - bislang kaum am Ziel eines »sustainable pace« orien- 
tiert und wird zu wenig im Sinne einer Selbstregulierung der Teams genutzt. 
Zugespitzt formuliert lernen die erfolgreichen Teams, wie man immer schneller 
läuft - aber nicht, dass man nicht fortwährend schnell laufen kann. Notwendig 
wären deshalb hier Lernprozesse in Richtung eines nachhaltigen Umgangs mit 
den Ressourcen im Team selbst. 


3.3.4 Zusammenfassung 


Das Fallunternehmen C ist ein Beispiel dafür, wie im Bereich IT und Software- 
Entwicklung im Kontext von Lean neue Arbeitsformen und Entwicklungsmo- 
delle flächendeckend zum Einsatz kommen, die das vormalige bürokratisch ge- 
prägte und am »Wasserfall« orientierte Organisationskonzept ersetzen. Hierbei 
geht es nicht um die isolierte Einführung einzelner Tools und Methoden oder 
die inkrementelle Optimierung der Organisation. Vielmehr entsteht ein grund- 
legend neues Entwicklungsmodell, welches in der Fläche über den gesamten 
Entwicklungsbereich ausgerollt wird. Die Zielvorstellung richtet sich dabei 
weniger auf die unmittelbare Steigerung der ökonomischen Effizienz und die 
Reduzierung von waste, sondern vor allem auf die Erhöhung der Steuerbarkeit, 
Planbarkeit und Transparenz der Entwicklungsarbeit. Mit diesem Paradigmen- 
wechsel kommt in der Praxis eine neue Qualität der systemischen Integration 
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zum Tragen. Mit der kurzzyklischen Taktung und dem Prinzip der Usable Soft- 
ware wird der individualistische »Expertenmodus« in Richtung kollektiver und 
systemisch strukturierter Organisationsmodelle geöffnet - die Suchprozesse 
nach einem »neuen Typ der Industrialisierung« gewinnen in diesem Untersu- 
chungsfall deutlich an Konturen. 

Die Einführung und Ausgestaltung dieses neuen Entwicklungsmodells er- 
weist sich in der Praxis als ein komplexer sozialer Veränderungsprozess. Sowohl 
die Notwendigkeit der Einbindung der Beschäftigten in die Implementierung 
als auch der Wandel in den Managementstrukturen, der das gewachsene orga- 
nisationale Machtgefüge in Bewegung bringt, führen dazu, dass die konkrete 
Umsetzung keineswegs einheitlich und bruchlos erfolgt. Die besondere Ent- 
wicklungsdynamik des Implementierungsprozesses und die damit verbundenen 
Aushandlungsprozesse zeigen sich insbesondere am Wandel der programma- 
tischen »Fahne«, unter der das neue Modell im Unternehmen vorangetrieben 
wird. Ausgangspunkt waren zunächst vor allem die agilen Methoden. Dieser 
Rekurs auf die positiv konnotierten agilen Methoden schuf erst die Voraus- 
setzung für eine aktive Beteiligung der Beschäftigten bei der Gestaltung des 
neuen Entwicklungsmodells. Der Durchbruch in der Breite erfolgte jedoch erst 
durch die Verknüpfung mit dem Lean-Konzept. Diese erweiterte programmati- 
sche Grundlage bildete dann nämlich ihrerseits die Basis dafür, dass nun auch 
das Management den Implementierungsprozess strategisch vorantrieb und in 
der Fläche durchsetzte. Aus soziologischer Perspektive gelang es dabei, die ur- 
sprüngliche »Künstlerkritik« der Beschäftigten zu inkorporieren und die Soft- 
ware-Entwicklung dann mit dem Lean-Konzept bis hin zu neuen Industrialisie- 
rungsformen zu öffnen. 

In der Folge haben sich der Entwicklungsprozess und die Arbeit der Ent- 
wickler grundlegend verändert. Auf der einen Seite wird die Entwicklung nun 
im Sinne einer getakteten Wertschöpfungskette organisiert, in die der Code 
der unterschiedlichen Teams kontinuierlich integriert wird. Der individuelle 
Entwickler kann nun nicht mehr »im Silo« entwickeln, sondern wird zum Be- 
standteil eines Teams, das in enger Interdependenz mit anderen Teams kurzzy- 
klisch Usable Software liefern muss. Auf der anderen Seite wird die Arbeit in der 
Entwicklung auch in neuer Qualität transparent. Ausschlaggebend hierfür sind 
sowohl die konsequente Zerlegung von Arbeitspaketen und ihre transparente 
Organisation im Backlog des Teams als auch die neuen Meeting-Routinen wie 
Daily Scrums, die auf eine Kollektivierung von Wissen zielen. Unsere Untersu- 
chung zeigt, dass die Belastungen für die Beschäftigten - trotz der salutogenen 
Potenziale der agilen Methoden - gestiegen sind. Unter dem Eindruck der Tak- 
tung verspüren viele »Dauerstress« und permanenten Zeitdruck. 
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In Hinsicht auf die Folgen für die Beschäftigten erweist sich das Empower- 
ment der Teams - das in den agilen Methoden konzeptionell verankert ist - als 
entscheidende Herausforderung. Es zeigt sich, dass sich Empowerment in vie- 
len Teams nur sehr eingeschränkt entfalten kann. Unter diesen restringierten 
Bedingungen sind die Beschäftigten jedoch mit den Anforderungen bzw. Be- 
lastungsfaktoren des neuen Modells - z.B. der Taktung oder der Transparenz - 
konfrontiert, ohne als Team wirklich handlungsfähig zu sein und Puffer bzw. 
Kompensationsstrategien in Anschlag bringen zu können. Dieses Gefährdungs- 
muster kommt nicht nur im Szenario des »potemkinschen Scrum« zum Tragen, 
sondern betrifft die strategische Entwicklung des gesamten Modells. Nach der 
eigentlichen Implementierungsphase haben die Institutionen und Routinen, die 
auf ein Empowerment der Teams gerichtet waren, in der Praxis mehr und mehr 
an Bedeutung verloren - während Taktung, Backlog und das Prinzip der Usable 
Software konsequent weitergeführt werden. 


3.4 Fallstudie D: Von Scrum zu Kanban - 
Neue Entwicklungsformen in der Software-Entwicklung 


3.4.1 Unternehmenscharakteristik und Ausgangsbedingungen 


Das Fallunternehmen ist ein weltweiter Anbieter von Software-Lösungen und 
Dienstleistungen für Unternehmen. Es beschäftigte zum Erhebungszeitpunkt 
mehrere Tausend Mitarbeiter weltweit, davon mehr als 1000 in Deutschland. 
Seit der Jahrtausendwende hat es einen Strategiewechsel vollzogen. Technolo- 
gischen Umbrüchen und dem Wandel der Märkte begegnet das Unternehmen 
nun vor allem durch den gezielten Zukauf und die globale Akquisition inno- 
vativer Unternehmen. Aus den beständigen Zukäufen resultiert heute eine zu- 
nehmende Heterogenität der Unternehmenslandschaft, denn jedes akquirierte 
Unternehmen bringt eigene Arbeitsprozesse und eine eigene gelebte Praxis in 
das Fallunternehmen ein. Daraus resultiert ein »Wildwuchs« unterschiedlicher 
Organisationsformen von Arbeit. Die zunehmende Heterogenität auf der einen 
Seite und die globale Ausdifferenzierung der Produktionsstrukturen auf der an- 
deren Seite bedeuten für das Unternehmen eine kontinuierliche Integrations- 
herausforderung. Dabei setzt man auf eine konsequente Vereinheitlichung der 
Prozesse und der zu Grunde liegenden IT-Systeme. Insbesondere im Bereich der 
Forschung & Entwicklung bzw. der Software-Entwicklung hat sich die Einfüh- 
rung von Lean als ein zentrales Werkzeug zur Integration der Organisation er- 
wiesen. 
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Im F&E-Bereich des Unternehmens sind in zwei Geschäftsbereichen zum 
Erhebungszeitpunkt knapp 1000 Entwickler weltweit beschäftigt. Der eine Ent- 
wicklungsbereich - aus dem das Unternehmen ursprünglich hervorgegangen 
ist — betreut die ursprünglichen Eigenentwicklungen des Unternehmens, die 
nach wie vor von zahlreichen Kunden genutzt werden und auf die ein signi- 
fikanter und stabiler Anteil des Umsatzes entfällt. Der andere Entwicklungs- 
bereich umfasst die nach der Jahrtausendwende akquirierten Firmen und somit 
die neuen Technologien, die das Unternehmen in die Zukunft führen sollen. In- 
nerhalb der Gesamtstrategie zeichnen sich damit für die beiden Entwicklungs- 
bereiche gegenläufige Entwicklungen ab. Während mit dem neuen Bereich im 
Sinne einer Wachstumsstrategie ein technologischer Umbruch bewältigt werden 
soll, ist die Situation in den traditionellen Entwicklungsbereichen des Unterneh- 
mens durch Kostenreduzierung und einen schrittweisen Konsolidierungs- und 
Schrumpfungsprozess geprägt. 

In den 2010er Jahren wurde begonnen, Lean in den beiden F&E-Bereichen 
einzuführen und mit je eigenständigen Zielsetzungen voranzutreiben. Der Aus- 
gangspunkt und Motor für die Einführung von Lean war zunächst der neu an- 
gebundene Entwicklungsbereich, der aufgrund der Heterogenität der Produkte 
und der globalen Ausdifferenzierung der Entwicklung vor einer tiefgreifenden 
Integrationsherausforderung stand. Ausgehend davon wurde Lean noch im sel- 
ben Jahr auch in den anderen Bereich übertragen. Zum Zeitpunkt der Unter- 
suchung war die Einführung von Lean in beiden Bereichen abgeschlossen. Ana- 
log zu Fallstudie C konnte auch hier mit Lean ein neues Entwicklungsmodell 
jenseits des alten Paradigmas der »Wasserfallprojekte« flächendeckend etabliert 
werden. Im Fokus steht dabei ein Fall, in dem nach anfänglichen Experimenten 
mit Scrum nun ein Kanban-Modell die Basis der Arbeitsorganisation bildet. 


3.4.2 Die Einführung von Lean 


Der Einführungsprozess von Lean im Unternehmen kann in zwei grundlegende 
Phasen unterteilt werden. In der ersten Phase, seit Ende der 1990er Jahre, wur- 
de in verschiedenen Projekten bereits mit agilen Methoden, wie z.B. Extreme 
Programming und Scrum, experimentiert. Die Initiative ging dabei von den Mit- 
arbeitern und einzelnen Projektleitern aus. Wie in Fallunternehmen C lassen 
sich diese Ansätze als »Grassroots«-Experimente verstehen, die sich jedoch nicht 
flächendeckend durchsetzten. In der zweiten Phase, die in den 2010er Jahren 
begann, wurde Lean in Kombination mit agilen Methoden auf Initiative des 
Managements »top-down« flächendeckend eingeführt. Diese Phase ist von der 
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Durchsetzung eines neuen Entwicklungsmodells und einer grundlegenden 
Neuorganisation der global verteilten Entwicklung geprägt. 

Der Ausgangspunkt für die Einführung von Lean war die Akquisition eines 
Unternehmens mit der Absicht, neue Produkte in das Portfolio aufzunehmen 
und mit der technologischen Entwicklung Schritt zu halten. Allein durch diesen 
Zukauf kamen mehr als 15 neue, global verteilte Standorte zum Unternehmen 
hinzu, die sich durch eine große Heterogenität von Arbeitsprozessen und -kul- 
turen auszeichneten. Weitere Zukäufe folgten. Damit stand das Unternehmen 
vor einer doppelten Herausforderung: Die Produkte des neuen Bereichs wurden 
von Hunderten global verteilter Entwickler erstellt. Ziel war es nicht nur, diese 
neu hinzugekommenen Arbeitskräfte und Tätigkeiten in die Organisation zu 
integrieren, die Strategie sah auch vor, dass die Produkte des neuen Bereichs suk- 
zessive mit den anderen Unternehmensprodukten integriert und systematisch 
verknüpft werden sollten. 

Zu dieser Zeit arbeitete die Software-Entwicklung, wie damals auch in ande- 
ren Unternehmen üblich, nach dem bürokratischen »Wasserfallmodell«. Die mit 
diesem Modell verbundene späte Integration der Teilprodukte führte in dem 
Unternehmensbereich zu Integrationsproblemen, hohen Fehlerzahlen kurz vor 
dem Release-Termin und zeitlich nicht abschätzbaren Phasen, in denen dann 
die Fehler unter hohem Druck behoben werden mussten. Dies resultierte in der 
Praxis häufig in der Verschiebung der geplanten Release-Termine. Diese Schwie- 
rigkeiten waren der Ausgangspunkt für eine systematische Auseinandersetzung 
mit der Herausforderung der Integration der Teilprodukte. 

Vor diesem Hintergrund gewann auch die Diskussion um die Einführung 
von Lean im Unternehmen an Bedeutung. Folgende Interviewpassage verdeut- 
licht die strategische Grundorientierung, die seinerzeit vorherrschte, und bringt 
das Verhältnis von Lean und agilen Methoden im Fallunternehmen zum Aus- 
druck: 


»Dieser Job, zuverlässig über die ganze Welt verteilt was zu produzieren, war der An- 
stoß, sich damit [mit Lean] intensiv zu beschäftigen. Der erste Antrieb, das war, eine 
Promotion hinzukriegen, eine Integration hinzukriegen, zuverlässig, jede Nacht, jede 
Woche, und etwas zu haben, was funktioniert. Und gar nicht mal, wir wollen agil 
arbeiten. Das ist was Tolles, agil zu arbeiten, da kommen wir schließlich nicht her. Es 
war aber auch klar, dass nur beides zusammen irgendwie Sinn macht und nur beides 
zusammen auch die Umwälzung hinkriegt, die wir brauchten.« (D-18) 


Durch Lean sollten die arbeitsteilig erstellten Teilprodukte nicht, wie im »Was- 
serfallmodell«, erst am Ende zusammengefügt, sondern kontinuierlich integ- 
riert werden, damit regelmäßig das Release eines funktionsfähigen Produkts 
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möglich ist. Der konzeptuelle Ausgangspunkt der neuen Entwicklungsorgani- 
sation war dem Interviewpartner zufolge demnach vorrangig Lean und weniger 
die agilen Methoden selbst. Die agilen Methoden wurden jedoch in enger Kom- 
bination mit Lean eingeführt, da nur so die Neujustierung der Entwicklung im 
Rahmen eines neuen Entwicklungsmodells möglich war. In der Praxis des Fall- 
unternehmens wird Lean dabei als ein teamübergreifender Ansatz verstanden, 
der die Organisation des Entwicklungsprozesses als Ganzes in den Blick nimmt 
und systemisch integriert. Demgegenüber werden die agilen Methoden als ein 
Instrument verstanden, das teamzentriert und auf die Organisation der Zusam- 
menarbeit der Teams fokussiert ist. 

Ausgehend von der Pilot-Einführung von Lean in den neuen Entwicklungs- 
bereichen wurde das Konzept noch im selben Jahr in den traditionellen Ent- 
wicklungsbereichen aufgegriffen und vorangetrieben. Der traditionelle Bereich 
befindet sich in einer besonderen Situation, weil seine Produkte teilweise schon 
seit mehreren Jahrzehnten auf dem Markt sind und weiterentwickelt und ge- 
pflegt werden. Zudem ist der Altersdurchschnitt der Entwickler vergleichsweise 
hoch. Manche sind seit mehr als 20 Jahren dort beschäftigt und arbeiten seit lan- 
gem am selben Produkt. Zentrales Ziel der Lean-Einführung war es hier, die his- 
torisch gewachsenen Strukturen »aufzubrechen« und den Bereich flexibler und 
besser steuerbar zu gestalten; mit einem stärkeren Fokus auf Teamarbeit und 
durch das Teilen von Wissen sollten nicht zuletzt auch Antworten auf die demo- 
grafische Entwicklung des Bereichs gefunden werden, der im Lauf der Jahre sehr 
abhängig von einzelnen Know-how-Trägern und Experten geworden war. 


3.4.3 Charakteristika des Entwicklungsmodells in der Software-Entwicklung 


Der konzeptionelle Kern von Lean im Fallunternehmen ist die ganzheitliche 
Sicht auf die gesamte Wertschöpfungskette, um das Zusammenspiel der einzel- 
nen Glieder optimal zu organisieren. Ziel ist dabei eine Organisation, in der die 
global verteilten Entwicklerteams, die gemeinsam an einem Produkt arbeiten, 
als systemisches Ganzes aufeinander abgestimmt agieren und regelmäßig ein 
integriertes Produkt an den Kunden liefern. Im Folgenden werden die zentralen 
Charakteristika des neuen Entwicklungsmodells dargestellt. 


Kurzzyklische und inkrementelle Entwicklung von »lauffähigen Systemen« 
Herzstück des neuen Entwicklungsmodells ist die kurzzyklische und inkre- 
mentelle Software-Entwicklung, die in einem sechsmonatigen Rhythmus ein 
Release hervorbringen und an die Kunden ausliefern soll. Eine Interviewperson 
erläutert das Neue von Lean anschaulich: 
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»Wenn Sie sich vorstellen, Sie haben 20 Teams, die entwickeln, und wenn man nach 
dem alten Modell arbeitet, dann wird entwickelt, entwickelt, entwickelt - und dann 
kommt die Deadline und wir müssen diese ganzen entwickelten Systeme oder Module 
integrieren. Und Lean bedeutet, dass man das permanent macht. Wir integrieren per- 
manent, und wir merken sofort, wenn etwas nicht zusammenläuft, und nicht erst am 
Ende.« (D-17) 


Zunächst werden die Releasezyklen so in vierwöchige Sprints unterteilt und 
auf sechs Monate verkürzt, innerhalb derer ein auslieferbares Produkt entwi- 
ckelt wird. Damit verändert sich die Zusammenarbeit der Entwickler deutlich. 
Während im alten Modus zu Beginn geplant wurde und die einzelnen Teams 
und Entwickler dann in voneinander abgeschotteten »Silos« arbeiteten, um erst 
am Ende ihre Teilprodukte zu integrieren, werden Planung und Entwicklung 
nun nicht mehr systematisch voneinander getrennt und die Zwischenprodukte 
»permanent integriert«. Erforderlich dafür ist frühzeitiges paralleles Testen und 
die Entwicklung von Test- und Integrationsumgebungen, mittels derer die Kom- 
patibilität und das Zusammenspiel verschiedener Teilprodukte schon in einem 
sehr frühen Entwicklungsstadium getestet werden können. 


Backlog als Basis für die arbeitsteilige Entwicklung 

Grundlage für die arbeitsteilige Entwicklung innerhalb eines Bereichs und für 
die bereichsübergreifende Abstimmung der Produkte ist der sog. »Backlog«, eine 
Liste von zu entwickelnden Features des neuen Software-Releases. In den Backlog 
gehen das Ziel der Integration neuer Produkte sowie neue Kunden- und Markt- 
anforderungen ein. Der Backlog wird halbjährlich vom Produktmanagement, 
einer von der Entwicklung unabhängigen Organisationseinheit, in Absprache 
mit dem Management festgelegt. 

Ausgehend davon wird eine priorisierte Liste von Features für den anste- 
henden sechsmonatigen Release-Zyklus erstellt und an die zuständigen Teams 
verteilt. Die Teamleiter, die im Fallunternehmen auch die Product-Owner-Rolle 
übernommen haben, sind für die Entwicklung der User Stories und die Zerle- 
gung der Features in einzelne Tasks bzw. Entwicklungsaufgaben zuständig. Um 
die Fortschritte der Entwicklerteams kontinuierlich zu evaluieren und Verzöge- 
rungen und Abhängigkeiten im Blick zu behalten, finden während des gesamten 
Entwicklungszyklus regelmäßige Abstimmungsmeetings statt, sowohl auf der 
Teamebene (Daily Scrums) als auch auf Führungsebene. Damit entsteht auch eine 
neue Qualität der Transparenz über den Entwicklungsprozess und die Fortschritte 
bei der Bearbeitung des Backlogs. Darüber hinaus wird die Entwicklung flexibler, 
indem die Entwickler im sechsmonatigen Rhythmus mit neuen Aufgaben ver- 
sorgt werden können und auch kurzfristige Umpriorisierungen möglich werden. 
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Systemisch integrierte Wertschöpfungsketten 

Die Basis der neuen arbeitsteiligen Organisationsformen in der Software-Ent- 
wicklung bildet ein IT-gestützter Arbeitsprozess. Er beinhaltet insbesondere das 
Tool Jira und eine komplementäre digitale Entwicklungs- und Integrationsum- 
gebung. Jira dient als System für die Zuteilung von Aufgaben und strukturiert 
den »Workflow« der Entwicklerteams, bildet den Backlog ab und dokumentiert 
den Status der einzelnen Aufgaben und damit den Aufgabenfortschritt.”' Die 
Entwickler »ziehen« aus diesem System ihre Aufgaben, bearbeiten sie und tra- 
gen den Status ein. Damit ist jederzeit ersichtlich, was als nächstes ansteht, wer 
für die Aufgaben verantwortlich ist und wie der Bearbeitungsstatus ist. Komple- 
mentär dazu wird die Arbeit durch eine Software-Entwicklungs- und Integra- 
tionsumgebung unterstützt, die der kontinuierlichen Produktintegration dient. 
Die Entwickler bearbeiten in der Entwicklungsumgebung ihren Code und spei- 
sen ihn kontinuierlich in die Integrationsumgebung ein. Dadurch kann schon 
in einem frühen Entwicklungsstadium das Zusammenspiel der unterschiedli- 
chen Teilprodukte getestet werden. Die Entwickler werden nach dem Testlauf 
informiert, ob die Integration funktioniert hat. Ist dies nicht der Fall, ist es ihre 
erste Aufgabe, den Fehler zu beheben. 

Zudem spielt in dem neuen Entwicklungsmodell die Kollektivierung von 
Wissen und damit die Entäußerung des individuellen Expertenwissens eine zen- 
trale Rolle. Im Zuge der Neuorganisation der Entwicklung wurde die Daten- 
bank, in der Wissensbestände statisch abgelegt wurden, durch ein IT-gestütztes 
internes Kollaborationstool abgelöst, um den Wissenstransfer und -austausch 
zu stärken. Die Entwickler speichern dort alle relevanten Informationen, kom- 
mentieren und ergänzen diese. Zentrale Charakteristik des Systems ist, dass die 
Informationen jederzeit von jedem (Zugangsberechtigten) bearbeitet werden 
können, wobei die Versionsgeschichte des kollektiv erarbeiteten Dokuments er- 
halten bleibt. Besondere Bedeutung hat das Wiki in Hinsicht auf die kontinuier- 
liche Weiterentwicklung und Verbesserung von Prozessen. 


3.4.4 Lean und das neue Entwicklungsmodell in der Praxis 


Im Folgenden wird anhand eines Fallbeispiels gezeigt, wie das neue Entwick- 
lungsmodell in der Praxis umgesetzt wurde und wie die Beschäftigten die damit 
verbundenen Veränderungen ihrer Arbeit erlebten. Das Beispiel, das aus dem 


21 | Anders als beim Shopfloor-Management in den Fallstudien A und B wird hier durch 
Jira ein durchgängiger »flow of information« geschaffen, wodurch die team- und be- 
reichsübergreifenden Schnittstellen bearbeitet werden können. 
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traditionellen Entwicklungsbereich des Unternehmens stammt, ist nicht zuletzt 
deshalb sehr aufschlussreich, weil hier nach Konflikten in den Teams ein eigen- 
ständiges Kanban-Modell (statt des ursprünglich geplanten Scrum-Ansatzes) ent- 
wickelt und umgesetzt wurde. Der Bereich ist, wie erwähnt, durch seine lange 
Tradition geprägt; hier werden Produkte gepflegt und inkrementell weiterentwi- 
ckelt, die schon lange auf dem Markt sind. Auch wenn weiterhin ein relevanter 
und stabiler Anteil des Umsatzes auf diese Produkte entfällt, ist das strategische 
Szenario davon gekennzeichnet, dass der Bereich sukzessive kleiner wird und 
Kosten gesenkt werden sollen. Heute arbeiten hier einige Hundert Beschäftigte, 
durchgehend ausgewiesene Spezialisten mit tiefen Kenntnissen der Produkte, 
großer Erfahrung und langjähriger Betriebszugehörigkeit. 

Das im neu akquirierten Entwicklungsbereich entwickelte Modell wurde 
vom Management als »Blaupause« aufgegriffen und im gesamten Bereich aus- 
gerollt. Dieser Schritt erschien dem Management einerseits notwendig, weil ei- 
nige Entwicklerteams im traditionellen Bereich Teilprodukte zum Portfolio des 
neuen Bereichs beisteuerten und bereichsübergreifende Schnittstellenprobleme 
vermieden werden sollten. Andererseits zielten die Führungskräfte darauf ab, 
die historisch gewachsenen Strukturen des Bereichs zu verändern, da die bis- 
herige Entwicklungspraxis angesichts der immer schneller werdenden Anforde- 
rungsänderungen in der Projektabwicklung für zu intransparent und unflexibel 
gehalten wurde. Durch die Einführung von Lean und agilen Methoden sollten 
die »verkrusteten Strukturen aufgebrochen« werden, die Entwickler aus ihren 
individuellen »Silos« geholt und in eine kollaborative Beziehung zueinander ge- 
bracht werden.” Die Zielsetzung wird von einer Führungskraft metaphorisch 
so dargestellt: 


»Das Bild ist Tanker versus Schnellboot. [...] Die Tanker, die wir einfach nicht um- 
steuern können, die einen Bremsweg von fünf Kilometer oder zehn Kilometer haben, 
Schnellboote, die praktisch auf der Stelle drehen können.« (D-18) 


22 | Aufschlussreich ist hierzu folgendes Zitat: »Wir im [Bereich I] haben Chancen da- 
rin gesehen, eine Veränderung herbeizuführen in Methoden, die zum Teil sehr verkrus- 
tet waren, auch in Teams, die zum Teil sehr verkrustet waren, in Strukturen, die sehr 
verkrustet waren. [In Bereich I ist es] keine Seltenheit, Leute, die 20, 25 Jahre dasselbe 
machen. Da sind auch Prozesse eingespielt. Und das ist zum Teil auch sehr gut gewesen, 
das hat einfach geflutscht, zum Teil aber auch extrem starr, dass da Silos sind, die mit- 
einander nicht so super kommunizieren, nur das Allernötigste, die Dinge sind nicht 
leicht änderbar.« (D-18) 
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3.4.4.1 Der Einführungsprozess von Lean und agilen Methoden 


Erste Phase: Konflikte um die Ausgestaltung 

Die erste Phase der Lean-Umsetzung mündete in eine Auseinandersetzung mit 
den Beschäftigten um die Ausgestaltung des neuen Organisationsmodells (zu 
Konflikten in der Teamarbeit vgl. z.B. auch Thursfield 2015). Sie zwang die Füh- 
rungskräfte zu Zugeständnissen und zu einer Neugestaltung der Arbeitsorgani- 
sation unter Beteiligung der Entwickler. Es lohnt sich, diesen umkämpften Ein- 
führungsprozess und die komplexen mikropolitischen Aushandlungsprozesse 
zu rekonstruieren, um die konkrete Ausgestaltung in der Praxis zu verstehen. 

Lean wurde zunächst in Kombination mit Scrum (als bedeutsamem Bestand- 
teil agiler Methoden) vom Management »nach Lehrbuch« eingeführt. Zentrales 
Element des Einführungsprozesses war dabei, dass die historisch gewachsenen 
Teams aufgelöst und als crossfunktionale Teams neu zusammengesetzt wurden. 
Die Idee dahinter war, eine heterogenere Zusammensetzung der Teams anzu- 
streben, damit die Teammitglieder voneinander lernen und individuelle Wis- 
senssilos aufgebrochen werden. Ausgehend davon wurde die Arbeit mit Scrum 
neu organisiert. Die Einführung von Lean wurde von den Entwicklern als radi- 
kaler Bruch erlebt und als »Paradigmenwechsel« bezeichnet. 

Das Entwicklungsmodell folgte klassischen Scrum-Prinzipien, d.h. die neu 
formierten crossfunktionalen Entwicklerteams sollten in einem einheitlichen 
Takt mit sechsmonatigen Release-Zyklen arbeiten, unterteilt in vierwöchige 
Sprints, an deren Ende jeweils Usable Software stehen sollte. Die Teams sollten den 
Aufwand für den jeweiligen (in Jira verwalteten) Sprint Backlog schätzen und da- 
nach eigenständig für dessen Bearbeitung verantwortlich sein. Der Arbeitsstand 
sollte in Daily Scrums dargestellt und evaluiert werden. Am Ende des Sprints 
sollten die entwickelten Features vorgestellt und im Review dem Product Owner 
und dem Management vorgestellt werden. Darauf sollte die Retrospektive folgen, 
in der im Team Verbesserungsvorschläge für die Entwicklungsprozesse und die 
Zusammenarbeit erarbeitet werden. Teil dieser Neuorganisation war auch die 
Einführung neuer Führungsrollen - Product Owner und Scrum Master. 

In der Praxis wurde dieses Modell von den Entwicklern kaum positiv an- 
genommen. Die erste Phase der Einführung war von dezidierter Ablehnung 
des Organisationsmodells und einer starken Unzufriedenheit der Beschäftig- 
ten geprägt. Diese Zeit wird von den Beschäftigten in den Interviews als sehr 
»unruhig« — teils »unerträglich« — geschildert, es sei »Stress« entstanden, und die 
Stimmung sei insgesamt sehr schlecht gewesen. Insbesondere das Konzept des 
crossfunktionalen Teams wurde als regelrechter Angriff auf das ausgeprägte Spe- 
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zialistentum begriffen, von dem das Selbstverständnis der erfahrenen Entwick- 
ler tief geprägt war. Dies beschreibt ein Entwickler anschaulich: 


»Seit ich beim [Unternehmen] bin, gibt’s für mich immer Spezialistentum, und hab 
schon immer so gearbeitet, dass man einen hatte, der für ein Produkt verantwortlich 
war, und der war auch, ich sag mal, Owner von dem Produkt [...]. Und der hatte auch 
das detaillierte Wissen und war dadurch in der Lage, relativ schnell Erweiterungen 
oder Änderungen einzubauen.« (D-10) 


Die Aufforderung, Wissen im Kontext des neuen Entwicklungsmodells nun syste- 
matisch zu teilen, wurde von vielen als Entwertung und als Mangel an Wertschät- 
zung begriffen. Darüber hinaus weckte die damit betriebene Kollektivierung 
von Wissen Ängste vor Austauschbarkeit. Ein befragter Entwickler schildert die 
Situation folgendermaßen: 


»Es blockiert keiner offen, aber es gibt sicherlich auch so, äh ja, so innere Widerstände, 
die nicht offen gesagt werden. Auch in dem Umfeld, im Sparumfeld, wo man halt unter 
Umständen dann um seine Stelle fürchten muss, da sagt sich natürlich der Spezialist: 
Puuuh, warum soll ich mein Wissen preisgeben? Wenn ich unentbehrlich bin, ist es 
besser für mich.« (D-8) 


Die Software-Entwickler haben mit ihrem Wissen ein Alleinstellungsmerkmal 
aufgebaut und wollen die Kontrolle über Ungewissheitszonen erhalten, um 
sich gegen Austauschbarkeit und Personalabbau zu schützen. Sie befürchten, 
dass durch Lean das Spezialistentum ausgehebelt wird, was einen Verlust ihrer 
Primärmachtpotenziale mit sich bringen könnte. Dieser Aspekt ist gerade im 
Kontext der erwähnten strategischen Orientierungen des Managements nicht zu 
unterschätzen, die in diesem Bereich auf Kostensenkung und Abbauszenarien 
hinauslaufen. 

Neben der Entwertung individuellen Wissens gerieten insbesondere auch 
die Taktung und das damit verbundene Planen und Schätzen der Arbeitsauf- 
wände in einem Sprint durch das Team in die Kritik. Bemängelt wurde, dass 
keiner der aufgestellten Vierwochenpläne funktionierte und diese durch externe 
Anforderungen und Interventionen des Managements außer Kraft gesetzt wur- 
den. Hintergrund hierfür war auch die hohe Maintenance- und Support-Last des 
Teams. Diese Aufgaben umfassten 60 bis 80 Prozent des Volumens der Team- 
aufgaben. Obwohl das Team ein Zeitbudget für die ungeplant auftretenden 
Maintenance-Aufgaben eingeplant hatte, konnte in der Praxis keine wirklich 
produktive Lösung für dieses Problem gefunden werden. Die zeitliche Taktung 
durch die Sprints empfanden die Entwickler als spürbare Zunahme von Druck. 
Darüber hinaus erlebten sie auch die Meeting-Routinen von Scrum und die hier- 
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mit einhergehende Transparenz negativ. So wird in Interviews z.B. das Daily 
Scrum als Kontrollinstitution und als »Gängelung« beschrieben. Die Entwickler 
argumentieren, dass sie als »gestandene« Entwickler wissen, was sie zu tun haben, 
und interpretieren diese verpflichtenden Treffen als Vertrauensverlust. Ein Ent- 
wickler beschreibt das Daily Scrum folgendermaßen: 


»Und dann gehen die Leute raus und sind frustriert, weil sie eben wie Schulkinder be- 
handelt werden. Und dann vor versammelter Mannschaft vorgeführt werden, wo sie 
jahrelang die Sachen machen, und das ist nicht jedermanns Sache, das ist einfach so, 
und das hat für sehr viel, sehr viel Unmut gesorgt.« (D-15) 


Die erste Lean-Einführungsphase endete, so kann man resümieren, mit deut- 
licher Unzufriedenheit der Beschäftigten und klarer Ablehnung des neuen Orga- 
nisationsmodells. Der Konflikt gipfelte in scharfer Kritik an der Neuzusammen- 
setzung der Teams, die als Angriff auf das historisch gewachsene Spezialistentum 
erlebt wurde und Befürchtungen nährte, »Primärmachtpotenziale« einzubüßen. 
Vor dem Hintergrund der strategischen Neuausrichtung des Unternehmens ge- 
wann die Auseinandersetzung zusätzliche Dynamik. 


Zweite Phase: 

Neugestaltung mit den Beschäftigten - Von Scrum zu Kanban 

Das Management reagierte auf die Konfliktkonstellation mit einem Zugeständ- 
nis an das Spezialistentum, das die Beschäftigten so vehement verteidigt hatten. 
Man entschied sich, die Entwickler selbst stärker an der Ausgestaltung des neuen 
Arbeitsmodells zu beteiligen. In der Folge wurden wichtige Momente des Ent- 
wicklungsmodells partizipativ verändert. Zentral und von hoher symbolischer 
Bedeutung war dabei die Zusammenstellung der Teams. Das »Team-Building« 
wurde nun den Beteiligten selbst übertragen. Zugespitzt formuliert wurden sie 
in einen »Raum gesperrt« und sollten diesen erst nach der erfolgreichen Bildung 
bzw. Neuzusammensetzung der Teams wieder verlassen. Von diesem Moment 
wird in den Interviews immer wieder berichtet: 


»Oh, bisher geht es ja immer von oben. Es wird bestimmt halt von oben - und das 
war was ganz Neues. Durch Überzeugungsarbeit hat sich unser Chef dann letztendlich 
davon überzeugen lassen, ja, nach dem Motto, wir sperren alle in einen Raum, wie bei 
der Papstwahl, und ihr kommt erst raus, wenn ihr eure Teams gebildet habt. So in der 
Art und Weise.« (D-24) 


Im Ergebnis entschieden sich die Beschäftigten, Teams zu bilden, in denen die 
alten Technologien gebündelt wurden; die wenigen Spezialisten, deren Wissens- 
domänen sich überlappten, wurden in einem Team zusammengefasst. Ansons- 
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ten wurde den Entwicklern - im Kontext des Lean-Modells - die Wahl der kon- 
kreten agilen Methode freigestellt. Dies führte dazu, dass Scrum angepasst und 
ein Rahmen gewählt wurde, den die Beschäftigten als weniger strikt erleben, 
nämlich Kanban. Während Scrum den Fokus auf crossfunktionale Teams legt, 
die in vierwöchigen Sprints arbeiten und für diesen Zeitraum den Workload 
eigenständig bestimmen, spielen diese Momente bei Kanban keine zentrale Rol- 
le. Der Fokus bei Kanban liegt vielmehr auf der kontinuierlichen Visualisierung 
des Arbeitsflusses und der Schaffung von Transparenz. 

Der gefundene Kompromiss führte zu einer Befriedung der Konflikte und 
Auseinandersetzungen. Der Anpassung der agilen Methoden wird von den Be- 
schäftigten ebenso wie von den Führungskräften eine große Bedeutung beige- 
messen; beide Seiten berichten, dass eine Form gefunden worden sei, die als 
erfolgreich erlebt wird und breite Akzeptanz genießt. In den Interviews wird 
immer wieder betont, dass die Beteiligten agile Methoden nun nicht mehr nach 
»Lehrbuch« umsetzen, sondern ihren eigenen Weg kreiert haben. Diese Form 
der Arbeitsorganisation hat sich seit mehreren Jahren bewährt und wurde nicht 
mehr grundlegend geändert. 


3.4.4.2 Kanban in der Praxis 

Das Entwicklerteam, das im Folgenden genauer betrachtet werden soll, setzt 
sich aus ausgeprägten Spezialisten zusammen, die verschiedene Produkte mittels 
unterschiedlicher Entwicklungsumgebungen bearbeiten und deren Wissensdo- 
mänen sich kaum überlappen. Das Team arbeitete zum Zeitpunkt der Untersu- 
chung bereits seit mehreren Jahren im Lean-Modus und hat dabei insbesondere 
mit dem neu gestalteten Kanban-Modell langjährige Erfahrungen. 


Taktung und die kontinuierliche Integration von Software 

Ähnlich wie bei Scrum ist die Arbeit des Entwicklerteams durch sechsmonatige 
Release-Zyklen strukturiert, an deren Ende jeweils ein getestetes und bereichs- 
übergreifend integriertes Produkt vorliegt, das an den Kunden auslieferbar 
ist. Die vierwöchigen Sprints wurden jedoch abgeschafft. Gleichwohl sind die 
sechsmonatigen Rhythmen noch in vierwöchige Zyklen unterteilt, diese die- 
nen allerdings lediglich einer unverbindlichen Zwischenauswertung und sind 
nicht mehr durch ein »Commitment« des Teams für ein bestimmtes, in den 
vier Wochen zu erreichendes Zwischenziel geprägt. In der Praxis entscheidend 
ist jedoch, dass das Team weiterhin am Prinzip der Usable Software festhält und 
die jeweiligen Teilprodukte kontinuierlich in einer Integrationsumgebung zu- 
sammenführt. Die Entwickler bearbeiten in der Entwicklungsumgebung ihre 
Teilprodukte und können diese täglich »einchecken« und damit für die Integra- 
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tion freigeben.” Die Integrationsprozesse werden in der Nacht durchgeführt, 
und am Morgen erhält jeder Entwickler die entsprechenden Ergebnisse. Dadurch 
kann schon in einem sehr frühen Entwicklungsstadium das Zusammenspiel der 
Teilprodukte getestet und an die Entwickler zurückgemeldet werden. Eine Be- 
schäftigte beschreibt, was dies in der Praxis bedeutet: 


»Ja, das ist die allerhöchste Priorität. Das ist für unser Tagesgeschäft das erste, was ich 
mache, wenn ich morgens komme: nach diesen Tests zu gucken. Und das macht jeder 
von uns, zu gucken, ob man irgendetwas machen kann, wenn etwas schiefgelaufen ist. 
Und dann tut jeder von uns alles dafür, dass die Tests wieder grün werden. Weil das 
muss funktionieren.« (D-21) 


Die materielle Basis der Arbeitsorganisation ist die IT-Plattform Jira. Das Pro- 
duktmanagement legt hier den Backlog für das Release an, und Jira funktioniert 
dann im Wesentlichen als »Ticket-System«, aus dem sich die Entwickler sukzes- 
sive die Aufgaben »ziehen«. Sie wählen dabei die Aufgaben entsprechend der 
im Backlog vorgegebenen Priorisierung und ihrer Kompetenz. So kann es in 
der Praxis der Fall sein, dass ein Entwickler für eine hochpriorisierte Aufgabe 
nicht die erforderliche Kompetenz besitzt und deshalb eine niedriger gewichtete 
Aufgabe wählt. Da die Aufgabenpakete sehr groß geschnitten sind und die Ent- 
wickler nicht kontinuierlich daran arbeiten, können sich die entsprechenden Tä- 
tigkeiten auch über mehrere Monate erstrecken. Wenn Aufgaben fertiggestellt 
sind, werden sie im Team präsentiert. 

Komplementär zur IT-gestützten Arbeitsorganisation durch Jira finden regel- 
mäßig »Stand-ups« statt, in denen die Entwickler des Teams berichten, woran sie 
gerade arbeiten und was bereits fertiggestellt wurde. Dies ist der Ort, an dem sie 
sich austauschen und Unterstützung für Aufgaben suchen. So beschreibt eine 
Interviewperson, dass diese Treffen sehr wichtig seien, weil sich dadurch die 
Kommunikation im Team deutlich verbessert habe: 


»Ich finde, die Kommunikation ist besser geworden. Also das ist, finde ich, ein Vorteil 
von diesem agilen Vorgehen. Wir treffen uns dreimal die Woche, und durch diesen 
Austausch kriegen wir sehr viel mehr mit voneinander und auch, wo die Probleme 
sind, und da ist auch eher eine Hilfsbereitschaft da. Wo jeder sonst so seins gemacht hat, 


23 | Der Prozess umfasst mehrere Teststufen, die sukzessive aufeinander aufbauen. Im 
ersten Schritt werden einzelne Module getestet, im zweiten Schritt gemeinsame Modu- 
le eines Produkts. Im dritten Schritt werden produktübergreifende Tests durchgeführt. 
Jeweils am Ende des Monats wird ein »Snapshot« mit den neuesten Features gemacht, 
der theoretisch an den Kunden geliefert werden könnte. 
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kommt da jetzt: Ja, du, ich kann dir da jetzt mal helfen. Also ich finde, die Kommuni- 
kation ist besser geworden.« (D-21) 


Während die Entwickler früher allein arbeiteten, werden sie nun durch das For- 
mat der »Stand-ups« aus ihrem »Silo« herausgeholt und setzen sich zueinander 
in Beziehung. Aufgrund des ausgeprägten Spezialistentums werden diese Tref- 
fen insbesondere zum Austausch und zur Unterstützung bei Problemen genutzt. 
Auch die Führungskräfte treffen sich regelmäßig, um den Bearbeitungsstatus, 
die Kalibrierung der Aufgaben und die Priorisierung zu besprechen und das 
Team zu steuern. Eine Führungskraft beschreibt dies folgendermaßen: 


»Also wir haben diese agile Methode, um ständig im Kontakt zu sein und den aktuellen 
Zustand zu betrachten, live auf verschiedenen Ebenen etabliert, um diese Flexibilität 
reinzukriegen.« (D-18) 


Interessanterweise wurden trotz des Wechsels von Scrum zu Kanban dietypischen 
Scrum-Rollen Product Owner und Scrum Master beibehalten, und zwar parallel 
zur bestehenden Führungsstruktur. So hat der Teamleiter die Product-Owner- 
Rolle übernommen und ist seit der Umstellung für die Unterstützung des Teams 
bei der Organisation der Arbeit zuständig.”* Das betrifft insbesondere das Zer- 
legen der Aufgaben, die vom Produktmanagement vorgegeben werden, und die 
Kommunikation mit dem Team. Dabei ist der in den agilen Methoden angelegte 
Konflikt zwischen Selbstorganisation und Führung immer wieder spürbar. Dies 
wird in folgender Passage einer Führungskraft deutlich, die sich über die Product 
Owner äußert: 


»Und ich bestärke sie auch durchaus in ihrer Rolle als Product Owner, auch mal zu sa- 
gen, was zu tun ist, nicht nur die Prioritäten vorzugeben. Fällt aber schwer, weil es gibt 
ja so eine Idee, was agil ist, und da ist es eigentlich nicht vorgeschen, dass man sagt: Du 
machst jetzt das! Aber es wird durchaus auch akzeptiert von Mitarbeitern, weil die das 
ja auch nicht immer schlecht finden, geführt zu werden. Da müssen wir den Mittelweg 
finden. Also für die ist die Rolle, die Veränderung fast noch schwieriger.« (D-18) 


Demgegenüber übernimmt der Scrum Master, ein Mitglied des Teams, organisa- 
torische Aufgaben für das Team, z.B. die Moderation von Sitzungen, und ist als 
»Vertreter« des Teams Ansprechpartner und Moderator bei Konflikten. Er ver- 
sucht seinerseits, den Teamgedanken und die Interessen des Teams zu wahren. 


24 | Zentrale Bedeutung hat hier das Produktmanagement als eigenständige Organi- 
sationseinheit. Es fungiert als »Geschäftsführer des Produkts« und als Vermittler zwi- 
schen der Entwicklung und der Außenwelt. 
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3.4.4.3 Wandel der Arbeit und die Perspektive der Beschäftigten 

Die Einführung von Lean und agilen Methoden wird von den Entwicklern als 
fundamentaler Wandel ihrer Arbeit erlebt. Dies wird insbesondere im Vergleich 
mit der Arbeitsweise zuvor deutlich. Die vormalige Arbeitsweise wird in den 
Interviews mit der Arbeit eines »freischaffenden Künstlers« verglichen; sie be- 
deutete große inhaltliche und kreative Freiräume, ganzheitliche Aufgaben und 
Eigenverantwortung. Mit der Umstellung habe, so ein Entwickler, ein »Para- 
digmenwechsel« stattgefunden. Eindrücklich wird dies in der folgenden Passage 
formuliert: 


»Also die schöne Welt, wie sie früher mal war, so der Nerd, der in Sandalen ins Büro 
kommt und sich hinsetzt, irgendwas Tolles programmiert, hackt, was man dann für 
[viel Geld] verkaufen kann, die ist lange vorbei, diese Zeit.« (D-11) 


Im Folgenden soll der Wandel der Arbeit aus der Perspektive der Beschäftigten in 
den Blick genommen werden, wobei drei Dimensionen eine hervorgehobene Be- 
deutung für das soziologische Verständnis haben: die Einbindung der Software- 
Entwickler in einen objektiven Arbeitsprozess, eine neue Qualität von Transpa- 
renz und Kontrolle und verschobene Kräfteverhältnisse in der Entwicklung. 

Einbindung der Entwickler in einen objektiven Arbeitsprozess - Soft- 
ware-Entwicklung »wie am Fließband«: Durch die Einführung von Lean und 
agilen Methoden sind die Entwickler mehr denn je in einen objektiven Arbeits- 
prozess eingebunden. Früher wurde die Gewichtung und Organisation verschie- 
dener Aufträge und deren Bearbeitung vom Entwickler selbst vorgenommen, 
wesentlich mitbeeinflusst von den eigenen Fähigkeiten und Interessen. Nun- 
mehr ist im IT-Iool Jira ein Backlog vorhanden, der vom Produktmanagement 
(in Absprache mit den Führungskräften aus der Entwicklung) vorgegeben wird 
und nur von diesem verändert werden darf. Ein Entwickler bringt die Verände- 
rung so auf den Punkt: 


»Früher war es ja so, [...] man bekam ein Problem gestellt oder eine Aufgabe, und 
die war sehr, sehr weit gefasst. Und man war allein dafür verantwortlich, die Planung 
durchzuführen, und letztendlich auch die Implementierung. Und mit dem Agil ist es 
jetzt so, dass das alles sehr kleine Aufgaben sind, [...] und man kommt sich so ein biss- 
chen vor wie, wie jemand, der am Fließband steht und nur kleine Teile entwickelt.« 
(D-10) 


Insbesondere der Verlust von Kreativität und inhaltlicher Mitbestimmung wird 
von den Entwicklern beklagt. Sie begreifen sich als erfahrene Spezialisten auf 
ihrem Feld, die wissen, was zu tun ist, und, so ein Entwickler, »wissen, wo es 
brennt«. Weil alle zu erledigenden Aufgaben in den Backlog aufgenommen sein 
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müssen, können die Entwickler nicht mehr selbst entscheiden, ob sie ein aus 
ihrer Sicht wichtiges Problem beheben. Dies wird in folgendem Zitat zum Aus- 
druck gebracht: 


»Jeder sagte nur: »Wo bleibt meine Kreativität? Ich ziehe da oben was vom Backlog 
runter und arbeite das dann ab und dann sehe ich das Nächste, da muss ich meinen 
Kopf ausschalten « (D-21) 


Die früher als Tätigkeit eines »freischaffenden Künstlers« wahrgenommene Arbeit 
erscheint nun als ein »Abarbeiten« von Positionen, die der Backlog vorgibt, wie 
am »Fließband«. Das zieht spürbare Veränderungen im Selbstverständnis und in 
der Wahrnehmung der eigenen Position nach sich: 


»Der Entwickler heute, ja, der ist eigentlich mehr so ein Arbeiter geworden. Der ist 
ein echter Arbeiter geworden. [...] also normaler Angestellter, der seine Arbeit macht.« 
(D-11) 


Neue Qualität von Transparenz und Kontrolle: Über Jahrzehnte galt die 
Arbeit der Entwickler als »Black Box«; sie konnte von außen nicht beobachtet 
und nicht hinreichend gesteuert werden. Folgendes Zitat bringt dies anschau- 
lich zum Ausdruck: 


»Also in dem Zusammenhang fallen mir die berühmten Worte eines Entwicklungs- 
kollegen aus USA ein, der immer, wenn man gefragt hat, kannst du mir schon mal was 
zeigen oder erklären, wie ihr das denn macht und so, dann immer gesagt hat: Way too 
early to show anything, to discuss anything. Und innerhalb von zwei Wochen drehte 
sich das dann zu: Way too late to change anything.« (D-7) 


Durch die Einführung neuer IT-gestützter Prozesse und deren Verkoppelung 
mit den Institutionen des Austauschs und der Kommunikation entsteht eine 
neue Qualität der Transparenz. Auf dieser Grundlage können die Entwickler- 
teams flexibel mit neuen Aufgaben konfrontiert werden, die in den Backlog ein- 
gehen. Darüber hinaus kann dadurch der Arbeitsstand des Entwicklerteams 
»live« eingesehen und gesteuert werden. 

Aus der Perspektive der Entwickler bedeutet dies, dass ihr Arbeitsbeitrag 
fortwährend offen liegt, »dass permanent sichtbar ist, an was man gerade arbei- 
tet und wie lange man daran arbeitet« (D-10). Die Folge ist, dass die Entwickler 
sich permanent unter Beobachtung fühlen. Dies wird in den folgenden beiden 
Passagen nachvollziehbar: 


»Das ist hier die wesentliche Veränderung. Dass man permanent gemonitort wird, wie 
weit man mit seiner Arbeit ist, und ob man jetzt plötzlich für eine Aufgabe viel länger 
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braucht. [...] und heute ist man nahezu jeden Tag unter Beobachtung, dass man mit 
dem einen Punkt noch nicht fertig ist. Und das ist was, ich sage, was unglaublich viel 
Druck erzeugt. Weil permanent alle Augen auf einen gucken, ob man vorankommt 
oder nicht.« (D-10) 


»Aber es ist eben nicht als Kontrollinstrument gedacht. Aber so wird’s von manchen 
Leuten gesehen, wenn’s auch nicht ausgesprochen wird, und so wird’s benutzt und so 
wird’s teilweise auch gelebt. Und das spüren die Leute natürlich.« (D-11) 


Die permanente Beobachtung und das Gefühl, »dass alle Augen auf einen gu- 
cken«, führen insgesamt zu einer Zunahme des Drucks. In der Folge werden 
Lean und agile Methoden nicht selten auch als neue Form von Kontrolle erlebt - 
in dieser Wahrnehmung als »Kontrollinstrument« kommen auch Vertrauensver- 
luste zum Ausdruck. Sie bilden einen wichtigen Hintergrund für die Vorbehalte 
der Beschäftigten gegenüber der neuen Arbeitsweise. 

Verlust von Handlungsspielräumen und verschobene Kräfteverhält- 
nisse: Durch die Einführung von Lean und agilen Methoden verschieben sich 
schließlich insgesamt die Kräfteverhältnisse im Entwicklungsprozess. Während 
früher der einzelne Entwickler eigenständig über seine Arbeitsinhalte bestim- 
men konnte und die Richtung in Entwicklungsprojekten vorgab, ist im neu- 
en Entwicklungsmodell das Produktmanagement zu einem mächtigen Akteur 
geworden, der die Ausrichtung der Entwicklung lenkt und steuert. Früher 
generierten die Entwickler Ideen, besprachen diese mit ihrem Vorgesetzten, 
übernahmen einen ganzheitlichen Auftrag und waren für dessen Bearbeitung 
verantwortlich. Durch die Einführung von Lean wird der Entwicklungsprozess, 
insbesondere durch Jira, in neuer Qualität formalisiert und transparent. Damit 
wird eine neue Grundlage für den direkten »Durchgriff« vonseiten der Füh- 
rungskräfte und des Produktmanagements geschaffen. 

Damit geht ein deutlicher Verlust von Handlungsspielräumen einher, der in 
den Interviews immer wieder aufgegriffen wird. Ein wichtiges Thema dabei ist, 
dass die Entwickler kaum mehr innovative Aufträge vorantreiben dürfen und 
hauptsächlich mit der Maintenance oder der inkrementellen Weiterentwicklung 
bestehender Funktionalitäten beschäftigt sind. Kern des neuen Modells ist, dass 
nun nichts mehr entwickelt werden darf, was nicht vom Produktmanagement 
genehmigt worden ist und im Backlog dokumentiert ist. Zwar können die Ent- 
wickler Vorschläge beim Produktmanagement einbringen, diese werden aber nur 
selten in den offiziellen Backlog aufgenommen. Während es früher durchaus eine 
Vielzahl an sogenannten »U-Boot-Projekten« gab, ist dies jetzt - da jederzeit ein- 
sehbar ist, woran die Entwickler arbeiten - kaum mehr möglich. Ebenso können 
die Entwickler nicht mehr eigenmächtig die anstehenden Aufgaben priorisieren. 
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Insgesamt erleben die Entwickler diesen Verlust von Handlungs- und Gestal- 
tungsspielräumen als Verlust von Verantwortung und auch als eine Verschiebung 
von Kräfteverhältnissen. Aufschlussreich sind hierzu die folgenden Passagen: 


»Man fühlt sich einfach der Verantwortung enthoben, dass man die Verantwortung 
entzogen bekam.« (D-10) 


»[Früher] war man mit den vielen anderen Mitarbeitern dafür verantwortlich, und heu- 
te merkt man, man ist nur ein ganz kleines Rädchen, und steuern tun das ganz andere.« 


(Ebd.) 


3.4.5 Zusammenfassung 


Lean und agile Methoden wurden in diesem Fallunternehmen auf Initiative des 
Managements top-down eingeführt. An der historischen Rekonstruktion des 
Einführungsprozesses wurde deutlich, dass die Einführung von Lean eng mit 
einer strategischen Neuorientierung des Unternehmens verbunden ist. Die Ak- 
quisition von Firmen hat zu einer Heterogenität und Ausdifferenzierung der 
global verteilten Entwicklungsstrukturen geführt. Ihre Integration stellt eine 
zentrale Herausforderung für das Unternehmen dar. Lean und agile Methoden 
erweisen sich als strategische Antwort darauf. Sie haben sich im Unternehmen 
als neues Entwicklungsmodell in der Software-Entwicklung durchgesetzt und 
etabliert. 

Der konzeptionelle Kern dieses Entwicklungsmodells ist eine ganzheitliche 
Sicht auf die gesamte Wertschöpfungskette, um das Zusammenspiel ihrer ein- 
zelnen Glieder von der Entwicklung bis zur Auslieferung des Produkts in neuer 
Form zu organisieren. Ziel ist es, dass die global verteilten Entwicklerteams, die 
gemeinsam an einem Produkt arbeiten, in ihrem systemischen Zusammenspiel 
abgestimmt agieren und kurzzyklisch Usable Software entwickeln, die im Rhyth- 
mus von sechs Monaten an den Kunden ausgeliefert werden kann. 

Die Falluntersuchung macht deutlich, dass die Einführung von Lean und 
agilen Methoden ein komplexer und umkämpfter sozialer Veränderungsprozess 
ist. Vor dem Hintergrund der spezifischen Rahmenbedingungen kommt es rund 
um den Einführungsprozess zu Konflikten und Auseinandersetzungen um die 
Ausgestaltung des neuen Entwicklungsmodells. Die Beschäftigten sehen insbe- 
sondere ihr »Spezialistentum« und die damit verbundenen Primärmachtpoten- 
ziale in Gefahr. Auch die Idee des »Commitments« und die damit verbundene 
eigenverantwortliche Planung der Arbeitsmenge des Teams werden als Belas- 
tung und stetige Quelle von Arbeitsdruck empfunden. In einem partizipativen 
Prozess einigen sich Beschäftigte und Mangement auf ein neues Modell, das 
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weniger dem klassischen Scrum-Prinzip folgt, sondern an die Idee von Kanban 
angelehnt ist. Damit können beide Seiten einen »Teilsieg« für sich erringen. Die 
Führungskräfte können die historisch gewachsenen Strukturen »aufbrechen« 
und die Arbeit der Entwickler transparenter und besser steuerbar machen, die 
Entwickler können die Kultur des Spezialistentums erfolgreich verteidigen. 

Allerdings geht mit diesem Modell ebenfalls eine grundlegende Veränderung 
der Software-Entwicklung einher. Denn auch im Kanban-System wird Software 
nun in einer getakteten und systemisch integrierten Wertschöpfungskette 
entwickelt. Die Entwicklungsprozesse werden durch sechsmonatige Release- 
Zyklen strukturiert, an deren Ende Usable Software steht und an den Kunden 
ausgeliefert werden kann. Die materielle Basis der Arbeitsorganisation bilden 
auf der einen Seite digitale Entwicklungs- und Integrationsplattformen, mittels 
derer die entwickelten Software-Bestandteile täglich (automatisiert) getestet 
und integriert werden. Auf der anderen Seite wird die Arbeitsorganisation 
selbst mit dem IT-System Jira gesteuert. Die Entwickler ziehen daraus ihre 
Aufgaben und tragen den Bearbeitungsstatus ein. Komplementär dazu finden 
regelmäßige Treffen »Stand-ups«) zum Austausch über den Arbeitsstand und 
zur gegenseitigen Unterstützung bei Problemen statt. Auf dieser Basis entsteht 
eine neue Qualität von Transparenz in der Entwicklung. Die Aufgaben, an 
denen die einzelnen Entwickler arbeiten, und der Arbeitsstand sind nun trans- 
parent und einsehbar. 

In der Praxis zeigt sich, dass die Beschäftigten mit der erfolgreichen Abwehr 
einer Scrum-Einführung langfristig möglicherweise einen »Pyrrhussieg« errun- 
gen haben. Denn ohne Prinzipien wie das »Commitment« und die damit ver- 
bundene (Selbst-JSteuerung der eigenen Arbeitslast fehlt ihnen der entscheiden- 
de Hebel für ein Empowerment des Teams. Während das Team in Scrum als eine 
autonome Einheit fungiert, hohe Gestaltungsspielräume hat, den Workload des 
Sprints schätzt und »commitet« und eigenverantwortlich für die Bearbeitung 
zuständig ist, gehen diese Optionen im Kanban-Modell verloren. Das Team hat 
hier keinen Einfluss auf den Workload, sondern arbeitet die anstehenden Aufga- 
ben »wie am Fließband« ab. Die Beschäftigten konnten so bei der Lean-Einfüh- 
rung zwar das historisch gewachsene Spezialistentum und ihre Primärmacht- 
potenziale verteidigen, der Preis dafür war jedoch die Aufgabe des Potenzials, 
als Team ein Mehr an Empowerment zu erreichen. Daran wird deutlich, dass die 
Einführung von Lean und agilen Methoden ein voraussetzungsreicher Prozess 
ist. Letztlich gilt: Nur unter Bedingungen von Sicherheit und Vertrauen können 
sich die darin angelegten Potenziale für Empowerment wirklich entfalten. Da- 
bei zeigt das Beispiel, dass Organisationsformen ohne Empowerment schnell zu 
einer Software-Entwicklung »wie am Fließband« werden können. 
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3.5 Fallstudie E: Von der bürokratischen zur agilen Organisation — 
Agile Methoden in der industriellen Forschung & Entwicklung 


3.5.1 Unternehmenscharakteristik und Ausgangsbedingungen 


Das Fallunternehmen ist ein weltweit agierender Konzern aus der Metall- und 
Elektroindustrie. Die deutschen Standorte des Unternehmens zeichnen sich 
durch eine starke betriebliche Mitbestimmung und einen relativ hohen gewerk- 
schaftlichen Organisationsgrad aus. Nicht zuletzt vor dem Hintergrund seiner 
dominierenden Marktposition kann sich das Unternehmen vergleichsweise mit- 
arbeiterfreundliche Beschäftigungsbedingungen leisten und hat so über Jahr- 
zehnte eine sehr spezifische sozialpartnerschaftliche Unternehmenskultur eta- 
bliert. Infolgedessen herrschen bei den Beschäftigten eine starke Bindung und 
eine hohe Identifikation mit dem Unternehmen vor. Obwohl das Unternehmen 
als multinationaler Konzern ein »Big Player« auf dem Weltmarkt ist, zeichnen 
sich seine betrieblichen Sozialbeziehungen durch eine ausgeprägte Vertrauens- 
kultur aus. 

Das Fallbeispiel steht für die Anwendung agiler Methoden zur Reorganisa- 
tion der Entwicklungsprozesse in einem hochinnovativen Bereich der Vorent- 
wicklung des Unternehmens. Den konkreten Rahmen hierfür bilden, anders 
als in den anderen Fallstudien, nicht die Ideen der Lean Production, sondern 
der Umbruch des Unternehmens in Richtung eines neuen Leitbilds der »agi- 
len Organisation«. Veränderte Marktbedingungen und die Herausforderungen 
der Digitalisierung bringen heute den bürokratischen Organisationsmodus des 
Unternehmens an seine Grenzen: Die zunehmende Komplexität der Produkte 
verträgt sich nicht mehr mit einer Struktur relativ unverbundener funktiona- 
ler Säulen (Entwicklung, Produktion, Vertrieb), abgeschotteter Wissensdomä- 
nen und starrer Hierarchien. Um den neuen Anforderungen zu begegnen, hat 
das Unternehmen verschiedene Initiativen gestartet, die allesamt dazu dienen 
sollen, das Unternehmen entsprechend dem Paradigma der Agilität neu auf- 
zustellen. Diese neue Leitorientierung zielt darauf, die Kundenorientierung zu 
stärken und insgesamt eine höhere Veränderungsflexibilität der Organisation zu 
erreichen. Insofern steht das Fallunternehmen exemplarisch für die Transfor- 
mation eines klassischen Industrieunternehmens in die digitale Ökonomie. Die 
Abkehr vom bürokratischen »Wasserfallmodell« zugunsten agiler Methoden in 
der Projektorganisation ist eines der zentralen Momente dieser Transformation. 
Damit sollen kürzere Innovationszyklen und eine generelle Erhöhung der Inno- 
vationsgeschwindigkeit realisiert werden. Die Hinwendung zu agilen Methoden 
ist jedoch zugleich auch eine Antwort auf die zunehmende Komplexität in der 
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Produktentwicklung im Zuge der Digitalisierung sowie auf die damit einher- 
gehende Herausforderung schnellerer Lernschleifen und einer Kollektivierung 
des Wissens der Mitarbeiter. 

Agile Teams gewinnen in sämtlichen Bereichen des Unternehmens - von 
der Entwicklung bis hin zum Verkauf - an Bedeutung. Die folgende Analyse 
befasst sich mit einem speziellen Fall der Anwendung von Scrum als agiler Me- 
thode der Projektorganisation im Bereich hochinnovativer Ingenieursarbeit. 
Eine Besonderheit ist, dass die hier zu untersuchende Projektgruppe die Scrum- 
Methodik selbst - d.h. ohne Unterstützung einer Zentralabteilung oder eines 
Beratungsunternehmens - an die spezifischen Anforderungen ihrer konkreten 
Arbeitsinhalte angepasst und kontinuierlich weiterentwickelt hat. Ein weiteres 
Charakteristikum des Falls besteht darin, dass hier eine Variante agiler Projekt- 
organisation entstanden ist, die uns gerade mit Blick auf den Verwirklichungs- 
grad des Empowerments erstaunt hat. Uns sind bisher nur wenige Fälle bekannt, 
in denen die Selbstorganisation und Eigenverantwortung des Teams so ausge- 
prägt und die Autonomie- und Entscheidungsspielräume der Mitarbeiter so 
weitreichend sind wie hier. 


3.5.2 Umbruch im Unternehmen - Auf dem Weg zur agilen Organisation 


Das Unternehmen steht aktuell vor grundlegenden Herausforderungen. Auf der 
einen Seite gilt es, sich mit Blick auf die Digitalisierung neu aufzustellen und 
nach einem neuen Bauplan für die Zukunft zu suchen. Auf der anderen Seite 
verändern sich auch die Märkte grundlegend, in denen sich das Unternehmen 
bewegt. So beginnt sich der vormals recht stabile und klar strukturierte Markt 
mit dem Aufstieg des Informationsraums und der Digitalisierung neu zu sor- 
tieren, sodass insbesondere die bisherigen Innovationsprozesse einem Wandel 
unterliegen. Auf der anderen Seite wird die vormalige Stabilität auch durch 
einen neuen Preiswettbewerb und steigenden Kostendruck in Frage gestellt, was 
nicht zuletzt auch die Beschäftigten verunsichert und die bisherigen, gewachse- 
nen Vertrauensbeziehungen belastet. 

Um besser auf die neuen Herauforderungen reagieren zu können, ist das 
Unternehmen auf der Suche nach einem neuen Organisationskonzept. Insbe- 
sondere die neuen Anforderungen, die aus dem Wandel der Innovationsprozesse 
und der zunehmenden Komplexität der Produkte resultieren, führen vor allem 
die Organisation der Wissensarbeit an die Grenzen des bürokratischen Modus. 
Lange Planungsvorlaufzeiten, starre, bürokratische Abläufe und Entscheidungs- 
prozesse sowie mehrjährige Innovations- und Entwicklungsprozesse erschweren 
oder verhindern eine schnelle Reaktion auf die rasante Veränderungsdynamik 
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der Märkte und Technologien. Um dennoch die Reaktionszeiten beschleunigen 
und auf außergewöhnliche Kundenanforderungen reagieren zu können, muss- 
ten bürokratische Regeln immer wieder punktuell außer Kraft gesetzt werden. 
Spezielle »Taskforces« bekamen dann - mit »Deckung von ganz oben« - die Er- 
laubnis, bürokratische Abläufe zu umgehen oder zu verkürzen, um z.B. kurz- 
fristig die Ausstattung mit Ressourcen anzupassen. 

Mittlerweile ist das Unternehmen aber mit den Anforderungen, die früher 
gelegentlich solche Ausnahme-Praktiken legitimiert haben, auf Dauer konfron- 
tiert. Im Zuge dessen lässt sich die Herausbildung einer neuen Leitorientierung 
erkennen: Vorstellungen einer »agilen Organisation« als Antwort auf die Gren- 
zen des bürokratischen Unternehmens zeichnen sich in einer Vielzahl punktuel- 
ler Aktivitäten und Initiativen ab. Diese zielen allesamt auf eine neue Beweglich- 
keit und Anpassungsfähigkeit der Organisation sowie auf einen entsprechenden 
»Mindset« bei den Mitarbeitern und Führungskräften. 

So werden beispielsweise in einem Pilotprojekt die Büros der Wissensarbei- 
ter durch offene Raumkonzepte und Desk-Sharing-Modelle in Kombination mit 
»Lounges« radikal umgestaltet und feste Arbeitsplätze aufgelöst, um den Aus- 
tausch und die Kommunikation in der Arbeit zu fördern. Neue Regelungen er- 
möglichen zudem eine neue Qualität von mobiler Arbeit und erleichtern das 
Arbeiten im Home Office, sodass starre Präsenzkulturen aufgeweicht werden 
und Mitarbeiter ihre Arbeit raum- und zeitflexibel gestalten können (und, vor 
dem Hintergrund neuer Raumkonzepte, auch müssen). Eine IT-basierte Ent- 
wicklungs- und Kollaborationsplattform wurde als eine Art »Betriebssystem« 
der agilen Organisation unternehmensweit ausgerollt und soll dazu dienen, den 
Transfer von Expertenwissen in der Organisation zu erleichtern, die Vernet- 
zung quer zu den einzelnen Geschäftsbereichen zu fördern und neue Formen 
Community-basierten Arbeitens zu etablieren. Gleichzeitig wird das traditio- 
nelle Führungsmodell nach dem Prinzip des »Fürsten im Reich« zunehmend 
infrage gestellt und mit neuen, innovativen Ansätzen des Coachings und der 
Selbstorganisation experimentiert. Dies geschieht nicht zuletzt im Kontext agi- 
ler Arbeitsformen, die in der gesamten Wissensarbeit im Unternehmen rapide 
an Bedeutung gewinnen. Überall - von der Entwicklung bis zum Verkauf - gibt 
es Versuche, agile Teams zu etablieren. Diese agieren, konsequent vom Kunden- 
nutzen ausgehend, mit einer iterativen Planung im Rahmen kurzzyklischer 
Intervalle und stellen eine Alternative zur bürokratischen Projektorganisation 
nach dem »Wasserfallmodell« und zu hierarchischen Entscheidungsprozessen 
dar, wie sie bislang im Unternehmen üblich waren. 

Die verschiedenen Aktivitäten und Initiativen sind zwar nur punktuell mit- 
einander verbunden und werden nicht zentral koordiniert, dennoch gehören sie 
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zusammen und bilden so etwas wie die Elemente eines neuen »Bauplans« für 
eine agile Organisation. Für die Mitarbeiter und Führungskräfte verbindet sich 
der Umbau zu einer agilen Organisation mit neuen Anforderungen und Heraus- 
forderungen: Sie sollen »die Komfortzone« verlassen und werden zunehmend 
als »mündige« Mitarbeiter adressiert: 


e Das individuelle Expertenwissen soll preisgegeben und neue Expertise perma- 
nent angeeignet werden: Sowohl über durchgängige IT-basierte Entwicklungs- 
und Kollaborationsumgebungen als auch durch die Installierung agiler Teams 
sollen die individuellen »Wissenssilos« aufgebrochen und die hochqualifizier- 
ten Experten in kollaborative und vernetzte Arbeitsprozesse eingebunden 
werden. Ziel ist es, individuelles Wissen in kollektives bzw. Organisations- 
wissen zu überführen. Damit verbunden sind auch neue Anforderungen im 
Sinne einer »kommunikativen Fachlichkeit« (Bultemeier/Boes 2013). 

« Es gilt, veränderungsflexibel zu sein und stets »über den eigenen Tellerrand 
hinauszublicken«: Das »Mindset« der Mitarbeiter soll an die Bedürfnisse der 
agilen Organisation angepasst werden. Sie sollen daran gewöhnt werden, dass 
es keine Gewissheiten mehr gibt und »nichts mehr fest ist«. Sowohl Standort 
und Arbeitsplatz als auch Teamzugehörigkeit und Arbeitsinhalt können sich 
jederzeit ändern. Maßnahmen wie die Regelungen zu mobiler Arbeit oder 
die Umgestaltung der Bürowelten bis hin zum Verlust fester Arbeitsplätze, 
aber auch die Anforderung, zeitweilig im Ausland zu arbeiten, zielen darauf, 
die Flexibilität der Arbeitskräfte zu erhöhen, mit alten Gewohnheiten zu bre- 
chen und offen für neue Impulse von außen zu sein. 

e Die Mitarbeiter sollen lernen, eigenverantwortlich zu agieren und nicht mehr 
lediglich auf Vorgaben und exakte Anweisungen von Vorgesetzten zu reagie- 
ren. Umgekehrt müssen Führungskräfte lernen, »loszulassen« und als »En- 
abler« für das Empowerment und die Selbstorganisation des Teams zu fungie- 
ren. Ausgehend von der Annahme, dass die hochqualifizierten Experten selbst 
am besten wissen, wie ihre Arbeit funktioniert, sollen sie diese auch selbst 
organisieren und planen. Die bestehenden bürokratischen Prozesse sollen von 
den Mitarbeitern hinterfragt und in »intelligente Prozesse« überführt werden, 
die immer wieder neu an die jeweils gegebenen Anforderungen angepasst 
werden können. 


Die neuen Anforderungen an Organisation und Mitarbeiter sind keinesfalls Aus- 
druck eines kohärenten und abgeschlossenen Konzepts. In unseren Interviews 
dominieren vielmehr unausgereifte Vorstellungen davon, was unter »Agilität« 
und »agile Organisation« zu verstehen sei. Je nach Bereich lassen sich quer durch 
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die Organisation zudem unterschiedliche Deutungen und Spielarten identifi- 
zieren. Insofern muss man eher von einem strategischen Suchprozess sprechen. 
Der Umbau zu einer »agilen Organisation« dient als Chiffre für die Suche nach 
einem neuen Organisationskonzept in den Kernbereichen der Wissensarbeit. 


3.5.3 Agile Methoden und der Wandel in Forschung & Entwicklung: 
Scrum in der Praxis 


Die neuen Anforderungen im Zuge des Umbaus zu einer »agilen Organisation« 
lassen sich besonders gut am Beispiel der Einführung agiler Methoden in der Wis- 
sensarbeit studieren. Hier findet sich gewissermaßen »im Kleinen« komprimiert, 
was sich »im Großen« vollzieht. So sind agile Teams in den verschiedenen Ge- 
schäftsbereichen des Unternehmens zunehmend verbreitet. Diese Entwicklung 
beruht allerdings nicht etwa auf einem flächendeckenden Roll-out einer Zen- 
tralabteilung, sondern ist das Ergebnis eines allgemeinen Trends, der sich unter 
unterschiedlichen Bedingungen jeweils unterschiedlich ausprägt. So lassen sich 
in der Praxis verschiedene, teils gegensätzliche Varianten identifizieren - von 
selbstgestrickten Scrum-Modellen über solche, die durch externe Coaches oder 
Beratungsunternehmen implementiert wurden, bis hin zu extrem standardisier- 
ten Varianten, die nur noch wenig mit dem eigentlichen Geist agiler Methoden 
zu tun haben. Auch die Größe der agilen Teams orientiert sich nicht konsequent 
am klassischen Scrum-Paradigma der »teams of ten«, sondern variiert bisweilen 
stark. Sie finden sich sowohl an den deutschen als auch etwa an den ausländi- 
schen Standorten und sowohl in unterschiedlichen Entwicklungsabteilungen 
als auch in anderen Angestelltenbereichen, wie z.B. im Vertrieb. 

Bei dem Fallbeispiel, auf das wir uns im Folgenden fokussieren, handelt es 
sich um eine Gruppe von Ingenieuren, die in einem Innovationsprojekt in der 
Vorentwicklung tätig sind. Die rund 30 Mitarbeiter des Projekts gelten als eine 
»Elitetruppe« mit handverlesenen Experten für bestimmte hochinnovative The- 
men. Die meist jungen, hochspezialisierten Mitarbeiter kommen aus der Uni 
oder sind ausgesuchte Spezialisten aus der Serienentwicklung. Das Projekt ist 
für die Beschäftigten besonders attraktiv - aufgrund seines innovativen Cha- 
rakters, aber auch weil davon auszugehen ist, dass es im Rahmen der globalen 
Arbeitsteilung auf absehbare Zeit in Deutschland bleiben wird. Anders als viele 
andere Bereiche am Standort gehört die Projektgruppe also nicht zu jenen Berei- 
chen des Unternehmens, die unter Kostendruck stehen und von Verlagerungen 
in Offshoring-Regionen bedroht sind. Vielmehr gilt sie nicht nur als sicher, son- 
dern - aufgrund des »Leuchtturmcharakters« im Unternehmen - sogar als eine 
Art Karrieresprungbrett. Insgesamt ist die Arbeit der Ingenieure hier durch ein 
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hohes Maß an Innovativität und Komplexität geprägt. Gleichzeitig genießt das 
Projekt eine hohe Aufmerksamkeit seitens der Geschäftsführung. 

Das Projekt hat innerhalb des Sets agiler Methoden konkret eine bestimmte 
Art von Scrum für die Ebene der Projektorganisation eingeführt, einschließlich 
der wichtigsten Institutionen und Konzepte (z.B. Daily Scrum, Sprint Planning, 
Retrospektive, Schätzen, Product Owner, Scrum Master). Andere agile Methoden, 
die cher die Arbeitsebene betreffen (z.B. test-driven development oder pair pro- 
gramming), scheinen keine Rolle zu spielen. Interessant ist ferner, dass es kei- 
ne direkte Verbindung zum Lean-Konzept gibt, wie wir es aus anderen Fällen, 
insbesondere in der Software-Entwicklung kennen (vgl. z.B. die Fallstudien C 
und D), wo Lean oftmals ein Komplement zu agilen Methoden darstellt. Das ist 
umso bemerkenswerter, als das Industrieunternehmen bereits seit Langem über 
ein eigenes Lean-Konzept in der Produktion (im Sinne »Ganzheitlicher Produk- 
tionssysteme«) verfügt. 

Die gelebte Praxis agiler Methoden unterscheidet sich so in einigen Aspek- 
ten markant von dem, was wir aus anderen Fallbeispielen kennen. Das betrifft 
sowohl den relativ hohen Verwirklichungsgrad des Empowerments und die 
konsequente Reflexion und Nutzung der kollektiven Lernerfahrung zur perma- 
nenten Anpassung der Scrum-Methodik als auch bereits die Umstände und das 
Muster des Implementierungsprozesses selbst. 


3.5.3.1 Gründe für die Einführung von Scrum: 
Komplexitätsbeherrschung durch Empowerment 

Gerade die besondere Komplexität und Innovativität des Projekts bilden den 
konkreten Hintergrund für die Einführung von Scrum im Fallbeispiel. An 
mehreren Stellen wird von unterschiedlichen Interviewpartnern immer wieder 
darauf verwiesen, dass die Einführung von Scrum in diesem besonderen Feld 
wichtige Vorteile biete.” In der Projektgruppe werden die Vorteile von Scrum 
vor allem in der Überwindung einer bürokratischen Projektorganisation sowie 
in der Überwindung eines bestimmten »Mindsets« und entsprechender Verhal- 
tensweisen der Ingenieure gesehen. So bezeichnet eine Führungskraft die Mit- 
arbeiter der Projektgruppe als Protagonisten eines neuen Typs von Ingenieuren, 
die er als »eigenverantwortliche Ingenieure« bezeichnet. Diesen Typus grenzt er 


25 | Gleichzeitig wagen sich selbst die überzeugtesten Verfechter agiler Methoden 
nicht so weit vor, Scrum generell als die Zukunftsmethode für das Engineering zu be- 
zeichnen. Vielmehr ist unter den Gesprächspartnern die Auffassung weit verbreitet, 
dass agile Methoden in traditionellen Projekten in einer seriennahen Umgebung bzw. 
in »klassischen« Kundenprojekten nicht funktionieren würden. 
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von einem »normalen Ingenieur« ab, der in den Kundenprojekten in serienna- 
her Umgebung tätig ist und den er für agile Projekte und den damit verbunde- 
nen »Führungsstil« für nicht geeignet hält. Er charakterisiert den traditionellen 
Typus und dessen Probleme im agilen Setting folgendermaßen: 


»Wobei ich auch davon überzeugt bin, ganz persönlich, Sie können es nicht mit jedem 
machen. [...] Weil ich glaube, und das ist überhaupt nicht wertend gemeint, sondern 
einfach eine Feststellung, ich glaube viele Mitarbeiter zu kennen, die sich wohler füh- 
len, wenn sie ein sehr klares Setting haben und wenn sie ganz klar gesagt kriegen: 
Heute machst du das, morgen machst du das und übermorgen machst du das. Das gibt 
denen eine gewisse Sicherheit, da ist einfach ziemlich klar, worüber sie sich Gedanken 
machen müssen. Und Priorisieren und Planen und all so ein Krempel liegt denen gar 
nicht. Die wollen ihre Themen bearbeiten. Ich glaube, die würden in so einem Füh- 
rungsstil überhaupt nicht glücklich werden.« (E-13) 


Aus der Umkehrung dieser Beschreibung wird deutlich, worin ein Vorteil agi- 
ler Methoden gesehen wird - nämlich in einer bestimmten Form der Arbeits- 
organisation, die einen empowerten Ingenieur hervorbringt, der in sich Planung 
und Ausführung vereint. Demgegenüber, so ist aus dieser Aussage zu schluss- 
folgern, sind es viele Mitarbeiter gewohnt, in einem Setting zu arbeiten, das auf 
einer Trennung von Planung und Ausführung und auf klaren Vorgaben aufbaut. 

Folgt man den Befragten, funktioniert ein solches bürokratisches Setting 
jedoch kaum in einem komplexen Innovationsprojekt. Dies wird an den folgen- 
den Ausführungen derselben Führungskraft deutlich, in denen die Vorteile der 
Scrum-Methodik für das Projekt reflektiert werden: 


»Trotzdem funktioniert sehr gut die Denkweise und der Spirit aus dem Scrum, näm- 
lich der von eigenverantwortlichen Teams, die im Grunde genommen im Dialog mit 
dem Product Owner verstehen, wo das ganze Ding eigentlich hin soll, was wir denn 
da brauchen, und sich ab dann selber Gedanken machen, wie sie das Ganze am besten 
erreichen. Das führt natürlich dazu, dass Sie eigenverantwortliche Ingenieure bekom- 
men, die eben Lücken, die Sie nicht gedacht haben, selber zu Ende denken. Und ich 
glaube, das ist auch so ein Schlüssel, weil so ein komplexes System versteht nicht mehr 
einer, der denkt nicht an alles. Sie müssen auch da so ein Subsidiaritätsprinzip haben, es 
muss, einer muss das große Gesamtbild im Kopf haben, aber dem werden Tausende von 
Details durch die Lappen gehen. Wie schaffe ich denn das, dass die Mitarbeiter diese 
Lücken füllen? Das brauche ich. Also da funktioniert für meine Begriffe ein Führungs- 
mechanismus top-down - ich sag dir genau, was du zu tun hast, du machst das - gar 
nicht. Weil das, was Sie vergessen haben, das ist in so einem Modell auch vergessen. Sie 
brauchen was, wo Sie sagen, pass auf, da und da will ich hin, ja, guck mal, wie du da 
hinkommst.« (Ebd.) 
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Die Führungskraft analysiert hier den inneren Zusammenhang zwischen den 
Besonderheiten der Arbeitssituation in der Projektgruppe und den daraus resul- 
tierenden Konsequenzen für die Arbeitsorganisation und das Führungsverhal- 
ten. Sie hält dabei insbesondere das »Subsidiaritätsprinzip« der agilen Arbeits- 
organisation hoch, schätzt also die Eigenverantwortung und Selbstbestimmung 
des Teams bzw. der Mitarbeiter, wodurch »Lücken« gefüllt und »Details« be- 
rücksichtigt werden können, die angesichts der Komplexität des Arbeitsgegen- 
standes von einem Einzelnen nicht planend vorweggenommen werden können. 
Folglich bedürfe es auch eines anderen Führungsstils, der nicht auf dem Top- 
down-Prinzip exakter Vorgaben beruht, sondern nur noch eine Orientierung, 
eine grobe Richtung vorgibt (»da will ich hin«), auf die Eigenverantwortlich- 
keit des Mitarbeiters vertraut und auf seine arbeitsinhaltliche Selbstbestimmung 
setzt. 

Daraus lässt sich schließen, dass es vor allem die Komplexität des Gegenstan- 
des ist, die es erforderlich macht, die üblicherweise praktizierte Trennung von 
Planung und Ausführung in diesem Projekt aufzuheben. Dies veranschaulicht 
auch ein Zitat eines befragten Mitarbeiters aus dem Projekt, der die Ungewiss- 
heitszonen und den Mangel an Kenntnis der konkreten Arbeitsprozesse beim 
Projektleiter und den Vorgesetzten betont: 


»Was ich sehe, und das ist wirklich interessant, wenn man eine Komplexität erreicht 
wie das Projekt, an dem wir arbeiten, und ein Entwickler formuliert User Stories, ist es 
für einen Product Owner, der schon eine Rolle hat von Verwaltung, könnt ich sagen, 
sehr, sehr schwierig, in die Tiefe des Themas einzusteigen, um wirklich zu verstehen, 
ob es tatsächlich etwas ist, das sinnvoll ist oder nicht. Weil im Prinzip das Know-how 
so unglaublich in einem sehr engen Bereich sich befindet. Es gibt keine Referenzen. 
Also der kann sich auch aus seinen eigenen Erfahrungen nicht abschätzen, ob der Mit- 
arbeiter tatsächlich die richtige Lösung anbietet oder das richtige Thema anbietet. Es 
ist sehr schwierig für ihn abzuschätzen. Er muss denen hundertprozentig trauen. Ist 
auch eine Grundlage von agilen Methoden. Man traut den Leuten, dass die wissen, 
aber es ist einfach für einen Product Owner sehr, sehr schwierig, das Thema an sich zu 
verstehen.« (E-5) 


Der Befragte gibt an, dass man im Rahmen des Innovationsprojekts mit einer 
Komplexität und einem Spezialisierungsgrad konfrontiert ist, die es für den 
»Product Owner« kaum noch möglich machen, die Arbeitsprozesse zu durch- 
dringen und das Vorgehen (die richtige Lösung«, »das richtige Thema«) fach- 
lich zu bewerten. Daher müssen die Mitarbeiter ihre Arbeit selber planen, was 
ein entsprechendes Vertrauen der Führungskräfte voraussetzt, wie es zu den 
Grundprinzipien der agilen Methoden gehört. 
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Zusammengenommen veranschaulichen die zitierten Aussagen, dass sich die 
Arbeitssituation im Projekt grundlegend von traditionellen Projekten unterschei- 
det. Durch die hohe Innovativität, Komplexität und Abstraktheit des Arbeits- 
gegenstandes wird ein Projektdesign nahegelegt, das sich auf die Expertenkom- 
petenz der eigenverantwortlich arbeitenden Ingenieure stützt, die als Spezialisten 
für ihre Domäne ihre Arbeit selbst inkrementell planen und die notwendigen 
Operationalisierungen vornehmen, die in einer herkömmlichen Top-down-Lo- 
gik ohnehin gar nicht mehr vorausgedacht, geschweige denn vorgeschrieben 
werden können. 

Insgesamt zeichnet sich das Fallbeispiel also durch einige Besonderheiten 
aus: Als »Elitetruppe« mit Avantgardecharakter ist das hochinnovative Entwick- 
lungsprojekt nicht nur mit einem ganz neuen Produkt und entsprechenden 
Anforderungen in der Wissensarbeit konfrontiert, sondern ebenso mit neuen 
Formen der Arbeitsorganisation im Kontext agiler Methoden, die ihrerseits den 
Versuch einer Antwort auf die neuen Anforderungen darstellen. 


3.5.3.2 Beteiligungsorientierte Vorgehensweise bei der Implementierung 

Zum Erhebungszeitpunkt arbeitet das Projekt bereits seit drei Jahren im Scrum- 
Modus. Die Befragten schildern die Einführung agiler Methoden als einen Pro- 
zess des eigenständigen Ausprobierens. Es hat sie niemand gezwungen, sie wa- 
ren auch nicht Gegenstand eines unternehmensweiten Roll-out. Es schien zwar 
im Unternehmen gewünscht zu sein, diese Arbeitsweise auszuprobieren - aber 
einen Zwang gab es nicht und auch keine konzeptionellen Vorgaben aus der 
Unternehmenszentrale. Auch hatten sie keine externen oder internen Berater, 
sondern haben das Konzept in Eigenregie initiiert, schrittweise und cher tastend 
weiterentwickelt und ausschließlich nach eigenen konzeptionellen Vorgaben ge- 
staltet. Bei dem in Anschlag gebrachten Konzept von Scrum hat man sich zu- 
nächst stark an der »reinen Lehre« orientiert, dann aber in weiteren Iterations- 
schleifen Anpassungen vorgenommen, um den speziellen Anforderungen der 
eigenen Arbeitssituation gerecht zu werden. 

Der entsprechende Lernprozess wird wie folgt geschildert: Im ersten Ver- 
such sei man bei der Einführung gescheitert. Dieses Scheitern resultierte aus 
systematischen Inkompatibilitäten der »reinen Lehre« des Scrum-Konzepts mit 
den spezifischen Gegebenheiten der Arbeitssituation im Projekt. In der Wahr- 
nehmung der Befragten gilt Scrum als eine Methode aus der Software-Entwick- 
lung, die für die Systementwicklung nur bedingt anwendbar sei. Hier habe man 
es mit Entwicklungsphasen von bis zu zehn Jahren zu tun und könne nicht alle 
vier Wochen fertige Produkte liefern. Es sei daher notwendig gewesen, Scrum 
mit Methoden des klassischen Projektmanagements sowie mit traditionellen 
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Engineering-Methoden, wie sie in der Serienfertigung angewendet werden, zu 
kombinieren.” Hier ging es vor allem darum, das Projekt vom Ende her zu kon- 
zipieren, ihm damit einen »Leitstrahl« zugrunde zu legen und die Meilensteine 
der Entwicklung vom Ende her zu bestimmen. In der Konsequenz wird darüber 
hinaus auch das Rollenkonzept von Scrum mit klassischen Führungsrollen kom- 
biniert (z.B. die Rolle des Product Owners mit der des Gruppenleiters) - ebenfalls 
ein Vorgehen, das ursprünglich im Scrum-Konzept nicht vorgesehen ist und von 
dem Experten sogar explizit abraten. 

Wesentliche Bedingung für den Erfolg dieses Lernprozesses war, dass die 
Institution der Retrospektive am Ende eines Sprints ernst genommen wurde. Sie 
zielt darauf, in regelmäßigen Abständen die Arbeitsweise in einem Team ge- 
meinsam zu überprüfen, um sie zu verbessern. Das setzt ein hohes Maß an Ehr- 
lichkeit und Vertrauen im Team voraus, damit Kritik offen formuliert werden 
kann und unangenehme Wahrheiten ausgesprochen werden können. Erst so ist 
es in dem Projekt gelungen, die spezifische Kombination des Scrum mit der Mei- 
lensteinplanung zu entwickeln. Das ist durchaus bemerkenswert, denn unserer 
Erfahrung nach geht in der Praxis der agilen Methoden - etwa in der industriel- 
len Software-Entwicklung - die Institution der Sprint-Retrospektive oft als erstes 
verloren. So wird dann, meist aufgrund eklatanten Zeitmangels, die Chance 
verpasst, die Retrospektive explizit als ein Mittel zur Entwicklung von gemein- 
samen Lernprozessen im Sinne kontinuierlicher Verbesserungen zu nutzen. In 
unserem Fallbeispiel war die Retrospektive aber offenkundig der entscheidende 
Erfolgsfaktor, um die spezifische, den Gegebenheiten adäquate Variante zu ent- 
wickeln. Und dies geschah - ein weiterer Erfolgsfaktor - beteiligungsorientiert 
durch das Team selbst, das eine Führungskraft als »reifes, eigenverantwortli- 
ches Team« beschreibt. Es sei kompetent, Probleme und Lösungsmöglichkeiten 
selbst zu erkennen, sodass die Führungskraft sich ihm gegenüber als »Dienst- 
leister« definieren sollte: »Wenn das Team zu Ihnen sagt, da und da funktioniert 


26 | Dass Scrum ursprünglich aus der Software-Entwicklung kommt, ist zwar richtig, 
aber ebenso richtig ist, dass die hier beschriebenen Anpassungserfordernisse auch in 
klassischen Software-Entwicklungsbereichen anzutreffen sind. Es handelt sich um An- 
passungen, die regelmäßig notwendig sind, weil sie aus Schwächen des Scrum-Konzepts 
selbst resultieren, die in der Systementwicklung und der Software-Entwicklung glei- 
chermaßen wirksam werden. Alle großen Unternehmen, die Scrum einsetzen, haben es 
mit einem Konzept kombiniert, das eine strategische Anlage der Produktentwicklung 
in mittleren und langen Fristen ermöglicht. Nicht zuletzt das ist der Grund, warum agi- 
le Methoden in der Praxis oft mit dem Lean-Konzept kombiniert werden (vgl. z.B. Boes 
et al. 2014a). Wahrscheinlich ist, dass dies einem prinzipiellen Konstruktionsfehler der 
agilen Methoden geschuldet ist. 
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was nicht, dann sind Sie ein Dienstleister, dann ist Ihr Job, das Ding wieder so 
gradezubiegen, dass das Team ordentlich arbeiten kann« (E-13). Empowerment 
und ein entsprechendes Führungsverhalten gehen hier also Hand in Hand mit 
einer beteiligungsorientierten Vorgehensweise. 

Die nächste Lernschleife, die sich bei der Einführung von Scrum in den 
Interviews identifizieren lässt, betrifft den Umgang mit dem Größenwachstum 
des Projekts. Das Projekt ist schnell gewachsen und steht nun vor der Heraus- 
forderung, »Unterstrukturen« einzuziehen. Auch dieses Problem wurde ein- 
vernehmlich vom Team in der Retrospektive und parallel vom Management er- 
kannt. Man ist sich bewusst, dass es unbedingt notwendig sei, dieses Problem 
der Skalierbarkeit von Scrum zu lösen, wenn man den Ansatz in die nächste Ent- 
wicklungsphase des Projekts mitnehmen will. Hintergrund der Einschätzung 
ist die Erfahrung, dass die bisherigen Organisationsstrukturen nicht mehr funk- 
tionieren, weil mit dem Wachstum die Kommunikation und die Abstimmung 
immer schwieriger werden. 

Zusammengefasst ergibt sich in Bezug auf die Besonderheiten bei der Imple- 
mentierung agiler Methoden im Projekt folgendes Bild: Erstens ist die Projekt- 
gruppe bei der Einführung ihr eigener Herr. Sie muss sich weder an einheitlichen 
Vorgaben einer Zentralabteilung noch an irgendwelchen Referenzsystemen in 
der Praxis orientieren, sondern hat ihre eigene Variante von Scrum entwickelt - 
ganz nach den spezifischen Anforderungen ihrer Arbeitssituation. 

Dies schlägt sich zweitens in einem speziellen Implementierungsmuster nie- 
der. Die Projektgruppe hat ein idealtypisches beteiligungsorientiertes Einfüh- 
rungskonzept etabliert. Es basiert darauf, dass die Ingenieure selbst die Subjekte 
der Veränderung der Organisation sind. Sie erkennen Veränderungsbedarfe, 
entwickeln Lösungen, setzen sie gemeinsam um und evaluieren sie. Dabei nut- 
zen sie vorrangig die Institution der Retrospektive. Das heißt also, die Selbstver- 
änderung ist integraler Bestandteil des Lernprozesses der Projektgruppe. 

Drittens hat das Projekt seit der Einführung agiler Methoden mehrere Lern- 
schleifen durchlaufen. Die erste Lernerfahrung resultierte aus einem Scheitern, 
das aber positiv verarbeitet wurde. Im Ergebnis wurden Elemente der traditio- 
nellen Projektmanagementmethode mit Scrum kombiniert, um eine strategi- 
sche Perspektive in den Projekten verankern zu können. Die nächste Lernschlei- 
fe dreht sich um die Skalierbarkeit von Scrum infolge des Größenwachstums. 
Auch wenn hier die gefundene Lösung bislang noch nicht voll zufrieden stellt, 
wurden auch hier erste Schritte bereits entwickelt. 

Die Vorgehensweise bei der Einführung agiler Methoden zeichnet sich im 
Fallbeispiel also durch hohe Autonomie, ein beteiligungsorientiertes Konzept 
und die konsequente Reflexion und Nutzung kollektiver Lernerfahrungen zur 
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Optimierung des Scrum-Konzepts aus. Seine spezifische Ausprägung und die 
Art und Weise, wie es in der Praxis konkret gelebt wird, werden im Folgenden 
genauer dargestellt. 


3.5.3.3 Framework — Routinen — Tools 
Das im Projekt entwickelte Scrum-Konzept ist sehr elaboriert und setzt alle we- 
sentlichen Institutionen um. Es geht in wesentlichen Punkten sogar weit über 
das hinaus, was wir aus vielen anderen Unternehmen kennen. Dies betrifft zum 
einen die Retrospektive (s.o.) und zum anderen das Schätzen des Workloads, das 
sich damit verbindende »Commitment« des Teams, generell den Aufwand, der 
für die Arbeitsplanung verwendet wird, und insgesamt die Hoheit des Teams 
bei der Definition der Arbeitsinhalte. Diese Momente sind wesentlich für den 
bemerkenswerten Realisierungsgrad des Empowerments im Untersuchungsfall. 
Grundsätzlich zeichnet sich das hier realisierte Konzept von Scrum durch 
eine iterative Planung in kurzzyklischen Sprints von jeweils drei Wochen aus. 
Anders als etwa in den Fällen C, D und F sind die einzelnen Teams hier aller- 
dings nicht in eine übergeordnete, bereichsübergreifend getaktete, kollaborative 
Wertschöpfungskette von teilweise mehreren Hundert Entwicklern eingebun- 
den, sondern agieren relativ autonom in einem mehr oder weniger abgeschot- 
teten Projektrahmen. Das Framework des Scrum-Konzepts orientiert sich im 
Wesentlichen an dem, was in der »reinen Lehre« ebenso wie in der Praxis grund- 
sätzlich üblich ist: Es gibt die Rollen Product Owner, Team und Scrum Master. 


Framework 
Der Product Owner (PO) steht außerhalb des Teams und repräsentiert die Per- 
spektive des Kunden. Er verantwortet das Produkt, entscheidet über die Pro- 
dukteigenschaften und priorisiert - im Austausch mit dem Entwicklerteam und 
dem Kunden - die Reihenfolge der Implementierung im Product Backlog. In 
unserem Fall wurde diese Rolle allerdings zweigeteilt: in eine Art »strategischen« 
PO für das Gesamtprojekt, der ausgehend von der allgemeinen Marktentwick- 
lung langfristige Entwicklungsschritte und Kernmerkmale des Gesamtsystems 
formuliert, und »operative« PO, die unmittelbar den Teams gegenüberstehen. 
Während der strategische PO die operativen PO orientiert, ist es die Aufgabe 
der operativen PO, die Langfristorientierungen in ihre Product Backlogs zu inte- 
grieren und als Schnittstelle zu den Teams und den Kunden zu agieren. Diese 
Kaskadierung der PO-Rolle ist in der Praxis nicht unüblich und findet sich in 
ähnlicher Form auch in anderen Unternehmen. 

Die Teams sind gegenüber den PO für die Lieferung der Produktfunktio- 
nalitäten und ihre Qualität verantwortlich. Sie sind interdisziplinär aufgestellt, 
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sodass die Systementwickler jeweils unterschiedliche Kompetenzen und Profile 
abdecken. Zu ihren Aufgaben gehört es auch, die Aufgabenbeschreibung (User 
Stories) in kleine Aufgaben für ihren Sprint Backlog zu zerlegen und so den kon- 
kreten Arbeitsplan für einen definierten Zeitraum (Sprint) festzulegen. Sie sind 
dabei insofern empowert, als sie den Umfang und Aufwand der einzelnen User 
Stories selber schätzen und somit ihren eigenen Workload definieren. Dass sich 
das Scrum-Konzept an dieser Stelle so stark »am Lehrbuch« orientiert, ist durch- 
aus bemerkenswert, denn viele Teams, die wir aus unseren empirischen Unter- 
suchungen kennen, scheitern gerade am Schätzen. Dies ist in diesem Fall offen- 
kundig anders: Das Schätzen wird in den Aussagen unserer Gesprächspartner 
sehr ernst genommen. Eine weitere Besonderheit ist ferner, dass die Teams ihre 
User Stories nicht von den PO diktiert bekommen, sondern sich die Entwick- 
ler diese selber schreiben. Das ist Ausdruck des erwähnten Umstands, dass der 
Gegenstand so innovativ und komplex ist und die PO dadurch meist nicht über 
die fachliche Kompetenz bzw. die inhaltliche Tiefe verfügen, um die richtigen 
Vorgaben zu entwickeln, sodass sie die User Stories der Entwickler nur kritisch 
hinterfragen und dann abnehmen und priorisieren können. 

Insgesamt besteht das Projekt zum Erhebungszeitpunkt aus vier Teams, die 
sich in ihrer Größe am Scrum-Paradigma der »teams of ten« orientieren. Die 
Teams sind in einer zweistufigen hierarchischen Struktur angeordnet. Ganz 
oben steht das Metateam, das für die Gesamtsicht auf das System verantwortlich 
ist und die Interdependenzen zwischen den anderen Teams im Sinne eines Scrum 
of Scrums koordiniert. Dementsprechend sind hier auch rotierend »Delegierte« 
aus den »Unterstrukturen« vertreten, und es ist daher auch etwas größer als die 
anderen Teams. Die darunterliegenden Teams sind für die Entwicklung einzel- 
ner Teilfunktionen des Gesamtsystems verantwortlich. 

Die Rolle des Scrum Masters dient dazu, die Umsetzung des Scrum-Konzepts 
mit den vereinbarten Institutionen und nach den vereinbarten Regeln zu ge- 
währleisten. Er organisiert Treffen, sorgt für die Arbeitsinfrastruktur des Teams 
und versucht, Hindernisse aus dem Weg zu räumen sowie Konflikte zu moderie- 
ren. In der konkreten Praxis der Teams wird diese Rolle meist in Personalunion 
von einfachen Entwicklern ausgeübt. Von den Gesprächspartnern wird sie weni- 
ger als »Hausmeister«Funktion beschrieben (wie das in anderen Unternehmen 
durchaus vorkommt), sondern eher als »Antreiber«, der das Team durch den 
Sprint leitet und darauf achtet, dass sich alle auch an den Routinen (z.B. Daily 
Scrums) beteiligen. Dabei agiere er allerdings nicht wie ein direkter Vorgesetzter, 
sondern »auf Augenhöhe, wie ein normales Teammitglied. 

Innerhalb dieses Frameworks besteht eine weitere Abweichung vom »Lehr- 
buch« darin, dass sich die Scrum-Rollen relativ oft mit disziplinarischen Füh- 
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rungspositionen überschneiden. So ist z.B. im Metateam die Rolle des PO von 
einem Gruppenleiter besetzt und die des Scrum Masters von einem Teamleiter. 
Auch dies ist in vielen Unternehmen durchaus üblich. Probleme, die daraus ent- 
stehen, schildert uns z. B. der Leiter des Projekts, der in der Vergangenheit eben- 
falls eine Zeit lang die Rolle des strategischen PO für das Gesamtprojekt inne- 
hatte. Er hat diese Rolle bald an einen Mitarbeiter abgegeben, weil er merkte, 
dass sie aufgrund seiner disziplinarischen Position in der Praxis nicht funktio- 
niert. Außerdem sei die Rolle ein »Fulltime-Job«, was sich mit seinen Aufgaben 
als Projektleiter nicht vertragen habe. 


Ablauf eines Sprints: Routinen und Tools 

Der konkrete Ablauf eines Sprints und das Vorgehen weisen ebenfalls einige 
Besonderheiten auf. Grundsätzlich arbeiten die Teams in einem Vier-Wochen- 
Sprint. Davon ist allerdings eine Woche nahezu komplett der Planung des Sprints 
bzw. dem Review und der Retrospektive vorbehalten, während sich die eigent- 
liche Abarbeitungszeit über drei Wochen erstreckt. 

Die Planung und Vorbereitung des Sprints beginnt damit, dass die Ent- 
wickler ihre User Stories definieren und beim Product Owner abliefern. Dieser 
bewertet die Priorität der einzelnen User Stories und trägt sie in ein IT-Tool (ana- 
log zu Fallunternehmen F wird dazu die Plattform RTC verwendet) ein, das 
faktisch den Drei-Wochen-Arbeitsplan (Sprint Backlog) des Teams abbildet. Die 
User Stories sind ein zentrales Tool für die Vorbereitung des Sprints, weil sie die 
konkreten Arbeitsaufgaben transparent und diskutierbar machen. Sie umfassen 
lediglich einen Satz und folgen immer einem einheitlichen Aufbau: Wer bin ich, 
was brauche ich und wofür? Konkret z.B.: »Ich bin das Metateam und benötige 
eine Systemreaktionstabelle, damit ich die Anforderungen für die Sensoren ab- 
leiten kann.« Wichtig sei, dass immer der Grund, warum man etwas braucht, an- 
gegeben werden müsse und am Ende immer ein konkretes Produkt bzw. etwas 
für sich Abgeschlossenes stehe. Generell sollen die einzelnen User Stories einen 
Arbeitsaufwand von ein bis zwei Tagen nicht überschreiten. 

Als nächstes folgt ein zweistündiges Meeting, in dem das Team gemeinsam 
den Arbeitsaufwand der einzelnen User Stories abschätzt. Die User Stories werden 
hier nach der Priorisierung durch den PO nacheinander abgehandelt, indem 
anhand der Komplexität der Aufwand geschätzt wird. Konkret erklärt zunächst 
der jeweils verantwortliche Entwickler, was sich hinter der von ihm definier- 
ten User Story verbirgt, und das Team schätzt gemeinsam den benötigten Auf 
wand im Rahmen eines Planungspokers. Dieses Tool funktioniert so, dass jedes 
Teammitglied die User Stories jeweils mit einer Anzahl von Story Points »von 
null bis unendlich«) bewertet, die auf einer Art »Spielkarte« stehen. In einer 
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sich anschließenden (kurzen) Diskussion werden stark abweichende Schätzun- 
gen mit dem Ziel erörtert, zu einer gemeinsamen Kalibrierung zu gelangen und 
erforderlichenfalls zu groß geratene User Stories weiter zu präzisieren und ggf. 
zusammen mit dem PO weiter zu zerlegen. Insgesamt zeigt sich am Beispiel 
des Schätzens, wie groß der Einfluss des Teams auf seine eigenen Arbeitsinhalte 
ist. Nicht nur schreiben die Entwickler ihre User Stories selbst und haben somit 
großen Einfluss darauf, woran und wie sie arbeiten - durch das gemeinsame 
Schätzen behält das Team auch die Hoheit über den Aufgabenumfang und Res- 
sourceneinsatz in einem Sprint-Zeitraum. Das heißt, dass die Teammitglieder 
ihren Workload selber kontrollieren können. So wird das Potenzial für die Rea- 
lisierung von Empowerment des Teams, das agile Methoden wie Scrum bereit- 
halten, hier weit ausgeschöpft. 

Nach dem Schätzen erfolgt das eigentliche Sprint Planning in einem relativ 
aufwändigen dreistufigen Prozess. Im ersten Schritt findet ein Planning Mee- 
ting von ca. vier Stunden Dauer statt, in dem das Team diskutiert, welche User 
Stories überhaupt für den nächsten Sprint berücksichtigt werden können, also 
realistisch mit den vorhandenen Ressourcen in drei Wochen abbildbar sind. 
Als Grundregel gilt hier, dass nicht mehr als 70 bis 80 Prozent der verfügbaren 
Arbeitszeit im Rahmen eines Sprints verplant werden sollen. 

Der nächste - meist zwei volle Arbeitstage beanspruchende - Schritt ist die 
Detailplanung, die jeder Entwickler individuell an seinem Schreibtisch bzw. mit 
dem RTC-Tool vollzieht, indem er seine User Stories in einzelne Arbeitspakete 
(Tasks) zerlegt, mit dem erforderlichen Zeitaufwand und mit den benötigten 
Ressourcen versieht - dazu gehört die gebotene Mitwirkung anderer Teammit- 
glieder. Indem das RTC für jedes Arbeitspaket Angaben verarbeitet, wer mit wie 
vielen Stunden gebraucht wird, kann es einen Überblick generieren, welcher 
Mitarbeiter zu wie viel Prozent verplant und wer ggf. überplant ist. 

Im letzten Schritt des Sprint Plannings, nach der individuellen Planungspha- 
se, wird noch einmal eine Kalibrierung der jeweiligen Kapazitäten und Ressour- 
cen im Team und mit dem PO vollzogen, in deren Verlauf ggf. die Aufgaben 
noch einmal umpriorisiert werden. Hier wird vor allem jede einzelne Person 
von ihrer individuellen Auslastung her betrachtet und bewertet, ob sie »noch 
Luft hat« oder ob man, wenn sie überplant ist, anders priorisieren muss. 

In der Folgewoche, unmittelbar nach dem Sprint Planning, startet dann der 
eigentliche Sprint, also die dreiwöchige Bearbeitungszeit, während derer der de- 
finierte Sprint Backlog abgearbeitet wird. In dieser Phase soll täglich ein Daily 
Scrum stattfinden, d.h. das Team kommt für kurze Zeit zu einem Stand-up-Mee- 
ting zusammen. Es dient dazu, sich darüber auszutauschen, an welchem Thema 
man gerade sitzt, wie der Status ist, ob man Unterstützung benötigt und ob 
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ggf. Terminkonflikte frühzeitig zu regeln sind. Der PO nimmt hier in der Regel 
nicht teil. Die Beteiligung der Teammitglieder an den Daily Scrums scheint aller- 
dings stark zu schwanken. Außerdem schätzen einige unserer Gesprächspartner, 
dass Daily Scrums in der Praxis nicht täglich, sondern lediglich ein bis zwei Mal 
in der Woche stattfinden. 

Nach Ende der Sprint-Phase folgen zwei weitere Routine-Meetings, die wie- 
der in der vierten Woche liegen, also in der Woche, in der außerdem die Vorbe- 
reitung und Planung des nächsten Sprints stattfindet. Im Sprint Review berichten 
die Entwickler an den PO und präsentieren die Ergebnisse, die sie jeweils im 
Sprint umgesetzt haben. Dies geschieht mit Hilfe von Folienpräsentationen und 
dient damit auch der Dokumentation von Ergebnissen im Sinne einer Versteti- 
gung von Wissen. Denn die Folien des Sprint Review werden im IT-System hin- 
terlegt, sodass einmal angestellte Analysen und erreichte Ergebnisse im Nach- 
hinein recherchierbar bleiben. Die abschließende Retrospektive dient dann dazu, 
den Sprint auszuwerten: Was ist gut gelaufen? Was ist schlecht gelaufen? Was 
hätte man besser machen können? 

Insgesamt ist der Aufwand, der hier insbesondere für die Planung des Sprints 
betrieben wird, tatsächlich bemerkenswert. Er ist Ausdruck dafür, wie ernst 
das Commitment des Teams für seinen Sprint Backlog genommen wird. In den 
Interviews wird sehr deutlich, dass in den Teams der Anspruch besteht, den 
Sprint Backlog innerhalb der drei Wochen auch wirklich so abzuarbeiten, wie 
man ihn geplant hat, bzw. ihn eben so zu planen, dass man ihn innerhalb der 
vorgegebenen Zeit abarbeiten kann. Das zeugt von einem relativ fortgeschrit- 
tenen Entwicklungsstadium der Teams. Weniger »reife« Teams zeichnen sich 
oft durch einen Fatalismus nach dem Motto: »Unsere Arbeit lässt sich eh nicht 
planen« aus, der die Ernsthaftigkeit in der Planungsphase unterminiert - und 
damit auch das Commitment und das Empowerment der Teams. Im hier unter- 
suchten Fall ist es - neben der Definition der eigenen User Stories, also dem Ein- 
fluss auf das »Was« der eigenen Arbeit - insbesondere das gemeinsame Schätzen 
der Aufwände, das ein echtes Empowerment ermöglicht, indem die Teams ihren 
Workload selbst bestimmen und kontrollieren können. Entsprechend ist auch 
die Haltung der einzelnen Teammitglieder bei der Planung des Sprints. So be- 
richten Befragte, die erst seit Kurzem im Projekt tätig sind, dass sie von ihren 
Kollegen eindringlich dazu angehalten werden, wirklich nur die User Stories zu 
planen, die sie auch realistisch in den drei Wochen abarbeiten können. »Schön- 
rechnen«, also weniger Stunden einzuplanen, als wirklich benötigt werden, 
werde nicht gern gesehen, wie eine junge Kollegin betont. Dass dieses »Schön- 
rechnen« damit aber noch nicht aus der Welt ist und in der Durchführung auf 
anderer Ebene kompensiert werden muss, werden wir unten noch vertiefen. 
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Der beachtliche Aufwand und die Konsequenz, mit der hier die Arbeit der 
Entwickler geplant wird, sowie das Empowerment des Teams bei der Festlegung 
ihres Workloads und bei der Definition ihrer Arbeitsinhalte sollen jedoch nicht 
darüber hinwegtäuschen, wie grundlegend der Umbruch der Arbeitsorgani- 
sation durch Scrum für die Ingenieurstätigkeit tatsächlich ist und welche Rei- 
bungspunkte sich dabei in der gelebten Praxis des Frameworks und der Institu- 
tionen offenbaren. Dies wird deutlich, wenn man das unmittelbare Erleben und 
die Perspektive der Beschäftigten einbezicht. 


3.5.4 Entwicklungsarbeit im Umbruch - Die Perspektive der Beschäftigten 


In den Gesprächen mit den Beschäftigten wird die Anwendung agiler Methoden 
sehr unterschiedlich bewertet. Auffällig ist, dass es eher die jüngeren Beschäftig- 
ten sind, die positiv urteilen und Vorteile von Scrum hervorheben. Dabei schät- 
zen sie insbesondere die Transparenz und den Einblick in die Arbeit ihrer Kolle- 
ginnen und Kollegen, aber auch umgekehrt die unterschiedlichen Perspektiven 
von außen auf ihre eigene Arbeit, die ihnen etwa im Rahmen des gemeinsamen 
Schätzens und der Diskussion ihrer User Stories Rückmeldung bieten. Hier sind 
es insbesondere das Lernen von den Erfahrungen der älteren Mitarbeiter und 
der Einblick in die verschiedenen inhaltlichen Themen, die sie als spannend er- 
leben und die für sie die Arbeit leichter machen. 

Auch bei den älteren Beschäftigten herrscht keineswegs eine überwiegend 
negative Sichtweise auf die agilen Methoden vor. Nur wenige von ihnen gehen 
so weit, diese lediglich als eine »Spielerei« abzutun. In den Interviews lassen sie 
jedoch insgesamt eine etwas differenziertere Sichtweise durchblicken. Sie sind 
zwar stets bemüht, die positiven Aspekte von Scrum zu betonen, registrieren 
aber auch Nachteile sowie Aspekte, die in der Praxis noch nicht so gut funktio- 
nieren. Beispielsweise werden zu hohe »Overheadkosten« beklagt, die aus dem 
Aufwand resultieren, den man für die Vorbereitung oder während des Sprints 
für das Pflegen des IT-Iools zur Dokumentation des Arbeitsfortschritts, für die 
Daily Scrums oder für die Folienpräsentation im Sprint Review betreiben muss. 
Ein Befragter schätzt, dass ein Fünftel bis ein Viertel seiner Arbeitszeit für »den 
Prozess drumherum draufgeht«. Auch wird die Transparenz, die die jüngeren 
Kollegen so schätzen, weil sie so besser lernen können, von den älteren Beschäf- 
tigten kritischer bewertet. Für sie verbindet sich diese z.B. im Rahmen der Mee- 
tings mit einem gewissen »Rechtfertigungsdruck« in Bezug auf den Fortschritt 
in ihrer Arbeit, den sie als unangenehm erleben und der auch dazu führen kann, 
dass sie zu Hause schlechter abschalten können. 
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Transparenz und Öffnung des Expertenmodus 

Die unterschiedlichen Sichtweisen insbesondere auf die neue Transparenz in der 
Arbeit hängen mit dem Umstand zusammen, dass die agilen Methoden auf eine 
Kollektivierung des individuellen Expertenwissens abzielen. Dieser Mechanis- 
mus wird in einem Interview mit einer jüngeren Entwicklerin anschaulich dar- 
gestellt. Ihr subjektiver Blickwinkel ist dabei exemplarisch für die Sichtweise ins- 
besondere der jüngeren Generation, die dies uneingeschränkt positiv als einen 
Vorteil der Scrum-Methodik interpretiert, der die Arbeit erleichtert: 


»Normalerweise [ohne Scrum] existieren Erkenntnisse dann irgendwo in den Köpfen 
und sie gehen für immer verloren, wenn der Kollege dann wechselt. Und so [in Scrum] 
muss man zumindestens mal Arbeitsergebnisse nachweisen, dass man irgendwas getan 
hat, [...] wir haben die und die Analyse gemacht, wir sind zu dem und dem Ergebnis 
gekommen, die Analyse liegt da und da. Also [...] haben wir zumindest mal eine Do- 
kumentation. Das heißt, wenn der Kollege dann geht und ein neuer Kollege kommt 
oder irgendwie nach sechs Monaten noch mal jemand auf die gleiche Idee kommt und 
keiner weiß mehr, dass man das schon mal gemacht hat, kann man immer noch [...] bei 
den Sprint Reviews mal nachgucken.« (E-14) 


In diesem Sinne scheint der Mechanismus, Arbeitsergebnisse kontinuierlich und 
öffentlich nachweisen zu müssen, ein wichtiger Effekt agiler Methoden in der 
modernen, hochkomplexen und innovativen Entwicklungsarbeit zu sein. Er ver- 
hindert, dass Wissen nur »irgendwo in den Köpfen« existiert oder Erkenntnisse 
verloren gehen, und führt dazu, dass sie breiter gestreut und anderen schneller 
zur Verfügung gestellt werden können. Gerade im Kontrast zum klassischen 
»Entwickeln im stillen Kämmerlein« wird die Veränderung durch die Öffnung 
der »Expertensilos« hier deutlich. 

Für die Befragte ist dabei vor allem die digitale Form der Ergebnisdokumen- 
tation entscheidend. Denn selbst wenn der Entwickler früher seine Ergebnisse für 
sich in seinen Notizen dokumentiert hat und selbst wenn diese zugänglich sind - 
»alles, was auf Papier landet, bleibt auf dem Papier und das Wissen ist dann für 
immer verloren, weil eben keiner sich noch mal die Mühe macht und dann irgend- 
wie rumblättert und auf 100 Seiten irgendwas raussuchen wird. Auf dem Rechner 
geht das, geht die Suche natürlich sehr viel schneller« (ebd.). Mit anderen Worten: 
Durch Digitalisierung liegen Informationen in einer Form vor, die für andere (bes- 
ser) zugänglich ist und überdies synchron genutzt werden kann, denn es sei auch 
wichtig, so unsere Befragte, »dass man wirklich zeitgleich alle Informationen parat 
hat und mit den Arbeitsergebnissen parallel arbeiten kann«. Komplementär dazu 
erleichtert die Öffentlichkeit, die im Zuge der Präsentationen im Sprint Review 
hergestellt wird, die Übersicht und die Orientierung auf der Informationsebene. 
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Was die junge Befragte hier uneingeschränkt als Vorteil und Erleichterung 
in der Arbeit darstellt - die Öffnung des »Expertensilos« durch Transparenz -, 
wird von älteren Beschäftigten eher als »Overhead« kritisiert. Der Hintergrund 
hierfür wird in folgender Textpassage deutlich, die die subjektive Perspektive 
eines älteren und erfahrenen Kollegen wiedergibt: 


»Und eine der Grundlagen z.B. von der Idee von agilen Methoden ist zu sagen, durch 
daily, also durch tägliche Absprache kann man sehr schnell sehen, wo es hakt, und 
man kann Unterstützung kriegen von anderen Leuten bei den Ressourcen und kann 
dadurch also sehr schnell halt Probleme lösen und diese, diese Arbeitsmenge verteilen. 
[...] Die Idee funktioniert gut in der Software-Entwicklung, wenn man bedenkt, das 
sind sieben, acht Software-Entwickler, die programmieren, alle haben das gleiche Pro- 
fil also von der Ausbildung her [...] haben sehr ähnliches Know-how, und die können 
dann sagen: Okay, ich übernehme jenen Teil oder ich kann das machen. Das funktio- 
niert bei uns allerdings nicht wirklich, weil wir sehr unterschiedliche Profile haben. 
Also wir haben gewisse Software-Entwickler, aber ich bin kein Software-Entwickler 
zum Beispiel. Dementsprechend kann ich nicht seine Aufgaben übernehmen. Selbst 
wenn der ein Problem hat, kann ich ihm nicht helfen. Das heißt, wir schen jetzt, wenn 
wir so Scrum-Aktivitäten machen, der Vorteil ist, man weiß, was die anderen machen. 
Unter Umständen gibt’s ein bisschen Überlappung. Aber es kann sehr gut sein, dass wir 
zwar gemeinsam arbeiten, aber eigentlich nicht zusammen wirklich direkt am gleichen 
Thema. Das sind alles unterschiedliche Themen. Das heißt, für mich sind das die Gren- 
zen von diesem Modell.« (E-5) 


Der Befragte hebt hier zunächst die »Idee von agilen Methoden« hervor und 
bezieht sich dabei explizit auf Vorteile wie Transparenz, Unterstützung und An- 
passbarkeit. Dann benennt er aber einen Widerspruch zwischen der Theorie 
und der konkreten Praxis in seinem Projekt. Das Problem sei, dass die einzelnen 
Profile der Teammitglieder zu speziell und zu unterschiedlich seien und es folg- 
lich zu wenige »Überlappungen« zwischen den jeweiligen Themen gebe, sodass 
man sich eben nicht gegenseitig unterstützen und helfen könne.” Man arbeite 
zwar »gemeinsam«, aber eben nicht wirklich »zusammen«. 


27 | Auch hier ist wieder der Verweis auf grundsätzliche Unterschiede zwischen Sys- 
tem- und Software-Entwicklung zu hinterfragen. Zumindest sind uns auch aus der in- 
dustrienahen Software-Entwicklung ähnliche Problembeschreibungen bekannt. Kurz 
gesagt scheint dies in Wahrheit kein Domänen-Problem, sondern schlicht eines des 
personellen »Staffings« von Projekten zu sein. Das bestätigt der Befragte auch selbst 
indirekt, indem er an anderer Stelle seine Hoffnung darauf setzt, dass genau dieses 
Problem sich in der Zukunft lösen könnte, wenn das Projekt in die nächste Stufe geht 
und sich um den Faktor vier oder fünf vergrößert, weil dann auch mehrere Mitarbeiter 
mit denselben Profilen vorhanden sein würden. 
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Dass die beiden genannten Haltungen in einem gewissen Widerspruch 
zueinander stehen, ist offenkundig. Einerseits wird der »Expertenmodus« der 
Entwickler (vgl. Boes et al. 2014a; Boes/Kämpf/Lühr 2016a) ein Stück weit auf- 
gebrochen und ihre »Wissenssilos« werden geöffnet. Andererseits machen die 
Entwickler aber die Erfahrung, dass die permanente Entäußerung ihres Wis- 
sens und die Offenlegung ihrer Arbeitsstände ihnen zumindest insofern nicht 
die Vorteile einer echten Kooperation bringt, als sie im Team nicht wirklich 
auf Unterstützung und gegenseitige Hilfe hoffen können. Vor diesem Hin- 
tergrund verwundert es nicht, wenn gerade ältere Kolleginnen und Kollegen 
den Aufwand für die Dokumentation ihrer Arbeitsstände und -ergebnisse als 
»Overhead« problematisieren oder gar - dies allerdings nur in Einzelfällen - die 
agilen Methoden generell als eine »Spielerei« abtun. Nicht zuletzt die schwan- 
kende Beteiligung an den Daily Scrums erscheint damit plausibel. So wird in 
den Gesprächen deutlich, dass sich nicht wenige Mitarbeiter gegen die »absolute 
Transparenz«, die sie im Zuge der Einführung agiler Methoden erfahren, sträu- 
ben. Beispielsweise werden die Aufwände für die einzelnen User Stories zwar 
gemeinsam geschätzt, aber der tägliche Status der Abarbeitung wird während 
der Durchführung des Sprints von den einzelnen Entwicklern meist nicht in 
das RTC-Tool eingepflegt, sodass ihr Arbeitsfortschritt nicht für jeden Kollegen 
(und damit natürlich auch nicht für die Vorgesetzten) einsehbar wird. Diese in- 
dividuellen Blockadehaltungen der Entwickler resultieren offensichtlich aus der 
Erfahrung, dass die Zunahme von Transparenz nicht zu einer Unterstützung in 
der Arbeit führt, sondern - wie im Folgenden zu zeigen sein wird - im Gegenteil 
den Leistungsdruck für den Einzelnen sogar noch erhöht. 


Zunahme des Leistungsdrucks 

Die Zunahme des Leistungsdrucks und von Belastungen in der Arbeit wird in 
vielen Interviews in einen Zusammenhang mit der Einführung agiler Methoden 
gestellt. So konstatiert selbst eine Führungskraft, dass die Entwickler »durch die 
Bank weg einem enormen Druck ausgesetzt« seien. Sie erläutert diesen Druck 
u.a. mit Blick auf das oben beschriebene, noch ungelöste Problem des Einzie- 
hens von »Unterstrukturen« nach Kompetenzen, das dazu geführt hat, dass die 
Verteilung der Zuständigkeiten für Plattform- und Kundenentwicklung unklar 
geblieben ist: 


»Weil der Mitarbeiter nicht mehr von sich sagen kann: Ich weiß genau, wofür ich nicht 
mehr zuständig bin, wenn ich mich dadrum nicht kümmer, dann ist es auch okay. Also 
wir haben eine sehr, sehr hohe Eigenverantwortung, wir haben eine sehr, sehr hohe in- 
trinsische Motivation im Team. Und dadurch, dass die alles sehen und alles wissen und al- 
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les kennen, wissen die ganz genau, an welchen Ecken wir überall Baustellen haben. Das ist 
der mündige Ingenieur, wenn man das so will, der also wirklich die komplette Breite des 
Schreckens sieht und sich dafür verantwortlich fühlt. Tja, dem nehmen Sie nicht mehr 
die Last von den Schultern, sich um gewisse Dinge nicht kümmern zu müssen.« (E-13) 


Vor dem Hintergrund formal ungeregelter Zuständigkeiten in einer Kultur ho- 
her Eigenverantwortung und intrinsischer Motivation steige der Druck für die 
Beschäftigten, weil sie »die komplette Breite des Schreckens« sehen können und 
sich prinzipiell für alles zuständig fühlen. Es sei gewissermaßen die Kehrseite 
des »mündigen Ingenieurs«, dass man ihm keine Last mehr von den Schultern 
nehmen könne. Damit steige die Gefahr der Selbstüberforderung. 

Einer der Beschäftigten schlägt zunächst in eine ähnliche Kerbe, indem er 
den hohen Leistungsdruck in einen Zusammenhang mit einer ingenieursspe- 
zifischen Leistungskultur stellt, die durch die agilen Methoden noch einmal 
verschärft werde. Im weiteren Verlauf schildert er ausführlich sein persönliches 
Leiden, das er sehr unmittelbar auf die gelebte Praxis des Scrum im Projekt zu- 
rückführt. Dabei problematisiert er zum einen den Verlust des eigenen Rhyth- 
mus in der Arbeit und zum anderen den Rechtfertigungsdruck, der aus der neu- 
en Transparenz resultiert: 


»Der Name »Sprint« ist gerechtfertigt in dem Fall bei uns, ja, muss man echt sagen. 
Unter anderem aber auch weil [...] gerade in Bereichen wie Entwicklung keiner da ist, 
um einfach also als Zuschauer unterwegs zu sein. Die Leute nehmen sich was vor und 
in 90 Prozent der Fälle nehmen sie sich zu viel vor. Muss man ganz chrlich sagen. Also 
die Leute, selbst wenn die ihre Stunden da hinbiegen, tatsächlich arbeiten die viel mehr 
dran als tatsächlich. [...] Also ich denke mal schon, dass es eigentlich ein stressigeres 
Arbeitsumfeld ist als ohne [agile Methoden], muss man einfach so sehen, für den Ein- 
zelnen. Das heißt, ich denke mal, es gibt, wie gesagt, sehr positive Aspekte, aber dass 
man das verkauft als eine lockere Arbeitsmethode, da bin ich nicht ganz einverstanden 
damit, weil, ich denk mal schon, dass insgesamt schon der Druck höher ist als ohne, als 
bisher. Bisher hat jeder seinen Rhythmus haben können. Das gibt’s nicht mehr in der 
agilen Methode. Du musst jeden Tag sagen, ich bin vorangekommen. Wenn nicht, wa- 
rum. Ich hab das Problem gehabt. Das heißt dieser tägliche Rhythmus, also für mich, 
ich weiß ganz genau, es gibt Tage, wo ich vielleicht 150 Prozent leisten kann und andere 
nur 50. Und dann gibt’s vielleicht drei Tage, wo ich, es kommt einfach nicht, wo man 
nicht wirklich weiterkommt und dann, dann gibt’s zwei Tage, wo man richtige Fort- 
schritte. In diesen agilen Methoden ist keine Möglichkeit im Prinzip, diesem persön- 
lichen Rhythmus zu folgen, weil, es wird so ein gewisser Fortschritt immer erwartet, 
und das ist etwas, was relativ belastend ist zum Teil. [...]. Ich denk mal, theoretisch 
wird man es dann keinem übel nehmen. Aber wie gesagt, man setzt sich selbst unter 
Druck.« (E-5) 
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Neben den Ausführungen zur Zunahme des Leistungsdrucks und zu dem Um- 
stand, dass ein »persönlicher Rhythmus« nicht zur Geltung kommen kann, ist 
hier die Auslegung der Scrum-Prinzipien interessant. Das Paradigma, bei der kol- 
lektiven Planung des Sprints nichts »schönrechnen« zu dürfen (s.o.), wird in der 
Durchführung des Sprints offenbar nicht konsequent gelebt. Tatsächlich arbeiten 
die Entwickler viel länger an ihren Aufgaben, als es z.B. durch die Statusdoku- 
mentation im RTC-Iool von außen nachvollziehbar ist, weil sie »ihre Stunden 
da hinbiegen«. Genau das scheint der Grund zu sein, warum sie ihren Arbeits- 
fortschritt dort nicht einpflegen, denn dann würde deutlich werden, dass sich 
das Team, trotz gemeinsamen Schätzens und kollektiver Planung, zu viel vor- 
genommen hat. 

Das Problem, das hier durchscheint, wird von einem anderen Beschäftigten - 
obwohl oder vielleicht auch gerade weil er zum Erhebungszeitpunkt erst seit kur- 
zer Zeit zum Projekt gehört - sehr klar und pointiert auf den Punkt gebracht: 


»Also wir machen die Arbeit, wir machen die ganze Vorbereitungsarbeit, und in der 
Durchführung sind wir schrecklich schlecht, und im Review hat dann immer alles 
funktioniert. Weil da halt auch [die Führungskraft] drinsitzt.« (E-7) 


Hier wird angesprochen, dass der Aufwand, der für die Vorbereitung des Sprints 
investiert wird, sich in der Durchführung des Sprints nicht auszahle. Das heißt 
im Grunde, dass nicht gut und richtig geplant wurde, sodass es bei der Abarbei- 
tung der Aufgaben zu Problemen kommt, die zum einen durch individuelle 
und intransparente Mehrarbeit kompensiert und zum anderen bei der Ergebnis- 
präsentation gegenüber der Führungskraft im Sprint Review unter den Tisch ge- 
kehrt werden. Was sich hier andeutet, scheint die Notwendigkeit einer anderen 
Führungskultur zu sein. Insbesondere die neue Transparenz, die mit den agilen 
Methoden einhergeht, erfordert eine Veränderung von Führung, z.B. im Sinne 
der Förderung einer adäquaten Fehlerkultur, die ein gemeinsames Lernen im 
Team ermöglicht. 

Insgesamt wird hier deutlich, dass das hohe Empowerment der Teams durch 
die vorherrschende Arbeits- und Leistungskultur konterkariert wird. Der hohe 
Leistungsdruck in Verbindung mit einer bürokratischen Arbeitskultur führt 
dazu, dass Probleme individuell kompensiert werden und im Verborgenen blei- 
ben, sodass sie nicht als Impuls für ein kollektives Lernen genutzt werden kön- 
nen. Infolgedessen erscheint der Leistungsdruck als ein individuelles Problem, 
das auf die intrinsische Motivation sowie den Ehrgeiz der Beschäftigten selbst 
zurückzuführen sei (weil »man sich selbst unter Druck setzt«), und nicht etwa als 
eine Herausforderung für die Führungskultur im Unternehmen. 
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Was den Erfolg bei der Implementierung des grundsätzlichen Modells von 
Scrum im Projekt ausgemacht hat - Probleme offen zu benennen und gemein- 
sam zu lösen -, scheint in der konkreten Durchführung von Scrum nicht immer 
zu funktionieren. Infolgedessen können die vorhandenen Mittel, wie das Schät- 
zen der Aufwände zur Kontrolle des eigenen Workloads, nicht zur Reduzierung 
der Belastung und des Leistungsdrucks genutzt werden, weil die Probleme nicht 
transparent gemacht werden. Dies lässt sich auch darauf zurückführen, dass der 
Sinn von Transparenz für die Mitarbeiter nicht erfahrbar ist, zum einen weil 
sich die Transparenz nicht mit einer neuen Führungs- bzw. Fehlerkultur verbin- 
det, die verhindern könnte, dass man sich unter Rechtfertigungsdruck gesetzt 
fühlt, und zum anderen weil gewisse Vorteile der Transparenz, z.B. die Identi- 
fizierung von Unterstützungsbedarf, wegen des hohen Spezialisierungsgrads der 
Themen und fehlender Überlappungen zwischen den inhaltlichen Profilen der 
Entwickler nicht realisiert werden können. 


3.5.5 Zusammenfassung 


Der Fall steht für die Transformation eines klassischen Industrieunternehmens, 
das sich den neuen Herausforderungen der digitalen Ökonomie stellt. In diesem 
Umbruchprozess gewinnen »agile Teams« in sämtlichen Bereichen des Unter- 
nehmens - von der Entwicklung bis hin zum Verkauf - an Bedeutung. Zwar 
folgen diese keinem einheitlichen Konzept. Ihre Gemeinsamkeit besteht jedoch 
darin, dass sie immer einen Versuch darstellen, die Grenzen des bürokratischen 
Organisationsmodells zu überwinden, um neuen Anforderungen in der Wis- 
sensarbeit gerecht zu werden. Das gilt auch für das hier untersuchte Innovations- 
projekt. 

Das Projekt hat für das Unternehmen einen Leuchtturm- bzw. Vorreiter- 
charakter. Die Arbeitssituation unterscheidet sich hier grundlegend von »klassi- 
schen« Entwicklungsprojekten. Der innovative Charakter des Themas, die hohe 
Komplexität und Abstraktheit des Arbeitsgegenstands sowie die entsprechende 
Expertenkompetenz der Ingenieure erfordern ein abweichendes Vorgehen in 
der Arbeitsorganisation. Die Hinwendung zu den agilen Methoden zielt dabei 
darauf, das bürokratische Setting traditioneller Projekte zu überwinden und 
mit Scrum ein anderes »Mindset« und entsprechende Verhaltensweisen der Mit- 
arbeiter zu erzeugen. Dies wiederum ist unbedingt notwendig, weil sich die 
Arbeit hier nicht weit im Voraus planen und top-down konzipieren lässt. Viel- 
mehr ist man auf eigenverantwortlich arbeitende Ingenieure angewiesen, die 
ihre Arbeit als Spezialisten für ihre Domäne selbst inkrementell planen und 
die notwendigen Operationalisierungen vornehmen. Das heißt, die Einführung 
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agiler Methoden zielt in diesem Fall auf das Empowerment der Mitarbeiter zur 
Überwindung der Unzulänglichkeiten traditioneller Projektorganisation, insbe- 
sondere der Trennung von Planung und Ausführung. Die Vorgehensweise bei 
der Implementierung agiler Methoden zeichnet sich dementsprechend durch 
eine hohe Autonomie, ein beteiligungsorientiertes Konzept sowie die konse- 
quente Reflexion und Nutzung kollektiver Lernerfahrungen zur Optimierung 
des Scrum-Konzepts aus. 

Insgesamt ist das so entwickelte Scrum-Konzept sehr elaboriert. Es geht in 
wesentlichen Punkten weit über das hinaus, was wir aus den meisten anderen 
Unternehmen kennen. Dies betrifft, neben der konsequenten Nutzung der Re- 
trospektive, vor allem das Schätzen des Workloads sowie das sich damit verbin- 
dende »Commitment« des Teams, den Aufwand, der generell für die Arbeits- 
planung betrieben wird, und die Hoheit des Teams bei der Definition seiner 
Arbeitsinhalte. Diese Momente sind wesentlich für den bemerkenswerten Rea- 
lisierungsgrad des Empowerments im Fallbeispiel. Dennoch ergeben sich in der 
konkreten Durchführung agiler Methoden Reibungspunkte und Widersprüche, 
die das hohe Maß an Empowerment konterkarieren. 

So kommt es im Zuge der Anwendung agiler Methoden zwar einerseits zu 
einer Aufweichung des klassischen Expertenmodus: So werden die Wissensbe- 
stände der Entwickler einer neuen Transparenz unterzogen und sie müssen ihre 
Zwischenergebnisse im Team präsentieren, die Planung ihrer Arbeit gemeinsam 
kalibrieren und sich bezüglich ihrer Arbeitsstände einem Rechtfertigungsdruck 
aussetzen. Andererseits können die Entwickler die Vorteile der Transparenz 
allerdings nicht für sich selbst nutzen. Beispielsweise können Probleme und 
Unterstützungsbedarfe zwar offengelegt und identifiziert werden, doch Unter- 
stützungs- und Entlastungsleistungen durch eine entsprechende Kooperation 
können nicht wirklich greifen, weil die inhaltlichen Themen und Profile der 
Entwickler zu speziell sind und sich zu wenig überschneiden. Im Zuge dessen 
kommt es zu Inkonsequenzen in der Anwendung der agilen Methoden und zu 
individuellen Blockadehaltungen, z.B. werden die Daily Scrums »geschwänzt« 
oder die Arbeitsfortschritte nicht im IT-Tool dokumentiert. Diese Blockaden 
resultieren aus der Erfahrung der Entwickler, dass die Zunahme von Transpa- 
renz nicht zu einer Unterstützung in ihrer Arbeit führt, sondern im Gegenteil 
den Leistungsdruck für den Einzelnen sogar noch erhöht. Der Leistungsdruck 
äußert sich unter anderem in der Anforderung, permanent Arbeitsfortschritte 
darstellen zu müssen. Dies führt dazu, dass individuell mehr und länger gearbei- 
tet wird, als vorher gemeinsam geplant war, was insbesondere von den älteren 
Beschäftigten als Belastung erlebt wird. 
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Zudem können die vorhandenen Mittel etwa zur Selbstkontrolle der 
Arbeitslast durch das Team nicht zur Reduzierung der Belastung und des 
Leistungsdrucks genutzt werden, weil die Probleme nicht artikuliert, sondern 
kaschiert werden. Das kann darauf zurückgeführt werden, dass der Sinn von 
Transparenz für die Mitarbeiter nicht erfahrbar wird, zum einen weil sie sich 
nicht mit einer Führungs- und Fehlerkultur verbindet (die verhindern könn- 
te, dass man sich unter Rechtfertigungsdruck gesetzt fühlt) und zum anderen 
weil gewisse Vorteile der Transparenz (wie eben die Identifizierung von Unter- 
stützungsbedarf) nicht realisiert werden können. Dahinter scheint ein anderes 
Problem zu stehen, das in dem Fehlen ausreichender Ressourcen für das Team 
und vor allem einer grundlegenden Orientierung auf Nachhaltigkeit als Ziel- 
stellung für die Anwendung agiler Methoden besteht (vgl. hierzu z.B. auch die 
Fallstudie C). 

Insgesamt führt die Implementierung agiler Methoden im Fallbeispiel so- 
mit zu einer Art »blockiertem Fortschritt«: Scrum ermöglicht zwar ein hohes 
Empowerment der Entwicklerteams. Durch die Unvollständigkeit und Inkon- 
sequenz in der Umsetzung werden die Potenziale des Empowerments jedoch 
nicht ausgeschöpft, um die Kontextbedingungen an die Erfordernisse einer 
agilen Arbeitskultur anzupassen. Der Expertenmodus wird nur einseitig auf- 
gebrochen: Die hohe intrinsische Leistungsmotivation wird durch die agilen 
Methoden genutzt und sogar noch akzentuiert, die Kontrolle über die Arbeits- 
gestaltung wird durch Transparenz und kollektive Planung auf die Teamebene 
gehoben, zugleich bleibt aber der einzelne Entwickler für seine Arbeitsergebnis- 
se individuell verantwortlich, sodass der Leistungsdruck steigt. Was nicht auf- 
gebrochen wird, ist die bürokratische Arbeits- und Leistungskultur des Exper- 
tenmodus, die einen offenen Umgang mit Fehlern und Problemen verhindert, 
sowie die Individualisierung des Experten in der Leistungserbringung selbst, die 
zwar ein gemeinsames Arbeiten erlaubt, aber keine wirkliche Kooperation im 
Sinne einer gemeinsamen Bearbeitung und gegenseitigen Unterstützung ermög- 
licht. Diese Konstellation scheint typisch für ein Unternehmen zu sein, das sich 
inmitten eines noch nicht abgeschlossenen Transformationsprozesses befindet, 
in dem sich Altes mit Neuem vermischt, sodass sich noch keine kohärenten und 
ausgereiften Strukturen herausbilden können, sondern Unabgeschlossenheiten, 
Diskordanzen und Suchprozesse dominieren. 
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3.6 Fallstudie F: Lean in der industriellen Hardware- und 
Software-Entwicklung — Hebel für eine neue Arbeitskultur? 


3.6.1 Unternehmenscharakteristik und Ausgangsbedingungen 


Das Fallunternehmen ist ein Industrieunternehmen der Metall- und Elektroindus- 
trie mit Hauptsitz in Deutschland. Es erwirtschaftet zum Erhebungszeitpunkt 
einen Großteil seines Umsatzes im Ausland. Weltweit werden mehrere 100.000 
Mitarbeiter beschäftigt. Nachdem der Schwerpunkt von Rationalisierungspro- 
zessen lange Zeit in den Produktionsbereichen lag, geraten in der aktuellen Pha- 
se der Umstrukturierung und Neuorientierung des Konzerns zunehmend die 
indirekten Bereiche - Vertrieb, Verwaltung, Forschung & Entwicklung - in den 
Fokus. Auf der einen Seite wird die Neuorganisation der Verwaltung mit großer 
Geschwindigkeit vorangetrieben. Hier ist die Gründung von Shared Services von 
zentraler Bedeutung. Im Fokus stehen die Standardisierung der Prozesse, die 
Konsolidierung der Standorte, die Eliminierung von Verschwendung und die 
Senkung der Kosten. Auf der anderen Seite finden sich auch im Forschungs- 
und Entwicklungsbereich erste Ansätze zu einer Neuorganisation. Hier spielt 
die Übertragung von Lean aus der Produktion eine zentrale Rolle. 

Der Konzern hat Mitte der 2000er Jahre eine Zentralabteilung für Lean ge- 
gründet, die direkt beim Vorstand angesiedelt ist. Diese war anfangs stark auf 
die Produktion fokussiert und verfolgte das Ziel, die Produktionssysteme der 
einzelnen Werke zu konsolidieren und im Unternehmen zu vereinheitlichen. 
Dies kulminierte in der Beschreibung eines konzernspezifischen »Ganzheitli- 
chen Produktionssystems«, das alle Funktionen der Wertschöpfungskette ab- 
deckt. Nachdem die Produktionssysteme in den direkten Bereichen konsolidiert 
waren, hat die Abteilung sich zunehmend mit der Frage beschäftigt, wie Lean in 
den indirekten Bereichen umgesetzt werden könne. Die Abteilung begleitet Pi- 
loteinführungen, unterstützt diese und legt den Rahmen des Konzepts anhand 
verschiedener Methoden fest. Auf dieser Basis werden ein Werkzeugkasten und 
ein Schulungskonzept für Berater entwickelt, die diese in der Fläche anwenden 
können. Anders als Fallunternehmen B verfolgt der Konzern zum Erhebungs- 
zeitpunkt keinen systematischen und konsequenten Roll-out in allen Geschäfts- 
bereichen, sondern ein »dezentrales Umsetzungskonzept«. Die Einführung von 
Lean wird nicht zentral vorgegeben, sondern es steht den Bereichen frei, Lean 
bei sich einzuführen. Gleichzeitig ist es die strategische Aufgabe der Zentralab- 
teilung, Lean in den Bereichen des Konzerns weiter voranzutreiben. 

Der Fokus der Fallstudie liegt auf dem Forschungs- und Entwicklungsbe- 
reich eines Geschäftsbereichs, der innerhalb des Konzerns ein Vorreiter für die 
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ganzheitliche Implementierung von Lean ist. Der Bereich beschäftigt ca. 1000 
Entwickler weltweit, davon mehrere Hundert in Deutschland. Die Produkte 
haben einen Lebenszyklus von zehn bis 20 Jahren und richten sich an Indus- 
triekunden, mit denen der Bereich stabile und langjährige Beziehungen pflegt. 
Das Unternehmen hat sich mit dem Bereich als ein wichtiger Player am Markt 
etabliert. 

Lean wurde in diesem F & E-Bereich bereits Ende der 2000er Jahre auf Initia- 
tive der Geschäftsführung und des mittleren Managements eingeführt und in 
Eigeninitiative vorangetrieben. Bis dahin basierte die Organisation von Arbeit 
hier auf einem typischen bürokratischen Prozessmodell, mit dem die Projekt- 
anforderungen jedoch immer schlechter bewältigt werden konnten. Lean wird 
hier als strategische Antwort auf die Grenzen bürokratischer Strukturen ver- 
standen; mit Lean soll der Entwicklungsprozess vollkommen neu gestaltet wer- 
den. Dabei wird ein ganzheitliches Konzept zugrunde gelegt. Der Fokus liegt 
nicht auf der Einführung einer Sammlung von Methoden und Tools, sondern 
auf einem systemischen Verständnis der Entwicklung. Die gesamte Wertschöp- 
fungskette von der Entwicklung bis zur Auslieferung an den Kunden wird in 
den Blick genommen. Der Bereich ist in der Umsetzung - auch im Vergleich zu 
anderen Fallunternehmen in unserer Studie - weit fortgeschritten. Zum Zeit- 
punkt der Untersuchung hat er das Pilotstadium bereits abgeschlossen und Lean 
ist flächendeckend eingeführt. Der Bereich steht zum Erhebungszeitpunkt vor 
der Herausforderung, Lean nachhaltig in der Organisation zu verankern. 


3.6.2 Das Scheitern des bürokratischen Prozessmodells 
als Ausgangspunkt für die Einführung von Lean 


Um zu verstehen, warum der Bereich Lean eingeführt hat, gilt es zunächst, die 
strategische Ausgangslage zu betrachten. Als Teil eines bürokratischen Großkon- 
zerns basierte die Organisation von Arbeit im Entwicklungsbereich auf einem 
bürokratischen Prozessmodell, das kontinuierlich weiterentwickelt wurde und 
über Jahrzehnte maßgeblich zum Erfolg des Bereichs beitrug. Angesichts neu- 
er Marktanforderungen im Kontext der Digitalisierung ist es jedoch mehr und 
mehr an seine Grenzen geraten, sodass das Management begann, die Arbeits- 
organisation in der Entwicklung grundsätzlich infrage zu stellen. 


3.6.2.1 Das bürokratische Prozessmodell als Sackgasse 

Der früher verfolgte Ansatz basierte auf dem qualitätszertifizierten Industrie- 
standard CMMI (Capability Maturity Model Integration«), einem »Reifegrad- 
Modell« der Entwicklung, das durch eine systematische Aufbereitung bewährter 
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Praktiken und die Standardisierung von Prozessen die Verbesserung der Orga- 
nisation von Entwicklungsarbeit unterstützt. CMMI umfasst fünf Reifegrade, 
die jeweils die Entwicklungsstufe eines Prozessgebiets definieren und auf jeder 
Stufe die Möglichkeit der Zertifizierung beinhalten. Der untersuchte Bereich 
erlangte im CMMI-Modell Mitte der 2000er ein für deutsche Verhältnisse sehr 
hohes Niveau. 

In den Anfangszeiten, so unsere Interviewpartner, hat das Modell maßgeb- 
lich die Erfolge der Entwicklung befördert, denn durch die Einführung von 
CMMI wurde zunächst eine Verbesserung der Termin- und Kostentreue in den 
Entwicklungsprojekten erreicht. Darüber hinaus war das hohe Niveau standar- 
disierter Prozesse beim Aufbau anderer Standorte von fundamentaler Bedeu- 
tung, da diese die Grundlage für die internationale Anschlussfähigkeit und die 
zuverlässige und effiziente Organisation global verteilter Arbeitsprozesse waren. 
Die Grenzen in der Anwendung des Modells wurden jedoch schon bald sicht- 
bar. Zwar konnten viele kleinere und mittlere Projekte anhand des Prozessmo- 
dells erfolgreich abgewickelt werden. Aber da die Komplexität und Größe der 
Projekte wuchs und sie zunehmend über mehrere Standorte verteilt bearbeitet 
wurden, konnte die Organisation mittels CMMI nicht mehr erfolgreich bewäl- 
tigt werden. 

Der Ausgangspunkt für die kritische Auseinandersetzung mit dem bürokra- 
tischen Prozessmodell war schließlich das Scheitern mehrerer strategisch wichti- 
ger, mehrjähriger Großprojekte. Sie wurden gemäß dem Prozessmodell Jahre im 
Voraus umfassend a priori geplant und gemäß der Planung bearbeitet. Trotz der 
intensiven Planung konnten in der Folge Release-Termine nicht eingehalten wer- 
den und mussten über mehrere Jahre hinweg immer wieder verschoben werden. 
Die Probleme führten zu einem hohen Druck auf die Geschäftsbereichsleitung 
und das Management. Mit Blick auf das Prozessmodell resümiert einer unserer 
Interviewpartner: »Das Genick haben uns am Ende tatsächlich zwei Mammut- 
projekte gebrochen.« War der Bereich vorher für sein hohes CMMI-Niveau über 
seine Grenzen hinaus bekannt, so hieß es nun: »Ihr beschäftigt euch nur mit 
Prozessen und arbeitet nicht für den Kunden und seid effektiv.« Insgesamt wird 
diese Zeit von den Beschäftigten und Führungskräften als Umbruch und Kri- 
senerfahrung beschrieben: beim Management, da die Entwicklung die »time 
to market« nicht halten konnte und als zu langsam und ineflizient galt; bei den 
Beschäftigten, weil sie sehr viele Überstunden leisteten und sich am Ende als 
»Prügelknabe« erlebten. 

Die Schwierigkeiten mit dem bürokratischen Prozessmodell werden in den 
Interviews ausführlich reflektiert. Ein zentraler Kritikpunkt richtet sich auf 
die Organisation des Arbeitsprozesses nach dem bürokratischen »Wasserfall- 
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modell«: Zu Beginn wurden die Projekte umfassend für ihre ganze Laufzeit 
geplant und bis ins Detail ausformuliert. Auf die Planungsphasen, die durch- 
aus ein Jahr dauern konnten, folgten lange Entwicklungsphasen, in denen die 
Teilprodukte sequenziell und arbeitsteilig erstellt, am Ende getestet und inte- 
griert wurden. In der Praxis offenbarte dieses Modell im Fallbeispiel mehrere 
Schwachstellen: Eine davon ist die im Zuge komplexer Großprojekte immer 
größer werdende Differenz zwischen Planung und Realisierung. Eine zweite 
wird durch die späten Test- und Integrationsphasen verursacht, wodurch Fehler 
erst spät entdeckt werden und mehrere Korrekturschleifen nach sich ziehen, 
die das entwickelte Produkt wiederum instabiler machen und zu Terminver- 
schiebungen führen. 

In der Folge wurde das bürokratische Prozessmodell im Unternehmen aus- 
führlich reflektiert und auf den Prüfstand gestellt. Demnach waren CMMI und 
die Standardisierung von Prozessen zwar für den Aufbau global verteilter Stand- 
orte ein wichtiger Entwicklungsschritt gewesen, allerdings hatte sich der Be- 
reich durch sein Prozessverständnis in eine »Sackgasse« manövriert und damit, 
so eine Interviewperson, eine »falsche Abzweigung« genommen. Es galt nun, 
von einem Verständnis formalistischer, wohldokumentierter, damit aber auch 
starrer Prozesse wegzukommen - Prozesse, die auch den Beschäftigten kaum 
Handlungsspielräume eröffneten. So wird in den Interviews immer wieder da- 
rauf hingewiesen, dass dieses Prozessverständnis ein »Korsett« darstellte, das re- 
gelrecht ein »De-Empowerment« der Mitarbeiter beförderte. Die starren Prozes- 
se führten dazu, dass die Entwickler kaum eine aktive und eigenverantwortliche 
Rolle im Entwicklungsprozess einnehmen konnten. 


3.6.2.2 Lean als strategisches Projekt zur Neuorganisation der Entwicklung 

Die Erfahrung der Grenzen des bürokratischen Prozessmodells war für das Ma- 
nagement der Ausgangspunkt, sich konsequent mit der Suche nach neuen Or- 
ganisationskonzepten auseinanderzusetzen. Eine Führungskraft fasst die Aus- 
gangslage zusammen: »Wir hatten einfach einen Druck, wir mussten irgendwie 
effizienter, besser werden.« Das daraufhin ausgegebene Ziel bestand darin, die 
Organisation von Arbeit grundlegend neu auszurichten. 

Bei der Suche nach einem passenden Organisationskonzept kam der Pro- 
duktion eine zentrale Bedeutung zu. Lean wurde in den Werken konsequent 
vorangetrieben; auch in dem Werk, das für die Produktion der Produkte des 
Bereichs zuständig ist, war wenige Jahre zuvor Lean eingeführt worden, und es 
wurden dort damit große Erfolge erzielt. Dadurch erhielt das Werk Referenzcha- 
rakter, denn es galt als effizient - nur die Entwicklung, so hieß es, »kommt mit 
ihren Projekten nicht raus«. Aus Managementsicht war das Konzept also positiv 
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besetzt, und es stellte sich schnell die Frage, wie es auch für die Entwicklung 
genutzt werden konnte. 

Das Management war überzeugt, dass durch die Einführung von Lean 
entscheidende Probleme der bestehenden Organisation von Arbeit adressiert 
werden konnten. Zum zentralen Ziel wurde dabei, die »time to market« zu re- 
duzieren. Mit Lean wurde also insbesondere angestrebt, statt langer planungs- 
getriebener Projekte auf kurzzyklische Entwicklungsprozesse zu setzen. Da- 
mit sollte sichergestellt werden, dass die Entwickler schnell auf sich ändernde 
Marktanforderungen reagieren können. Indem die Produkte kurzzyklisch an 
den Kunden ausgeliefert werden, wird eine neue »Kundenorientierung« mög- 
lich, denn die Produkte können frühzeitig vom Kunden evaluiert werden, und 
dessen Feedback kann im nächsten Release-Zyklus aufgenommen werden. Die 
Einführung von Lean wird insgesamt als strategisches Projekt zur Neuorgani- 
sation der Entwicklung verstanden. Der konzeptionelle Fokus liegt einerseits 
auf »Generating Value without Waste« und damit auf der Vermeidung von Ver- 
schwendung. Andererseits wird die Neuorganisation der Entwicklung durch 
Lean vor allem als ein »ganzheitlicher Ansatz« zur Neuausrichtung der gesam- 
ten Wertschöpfungskette - von der Entwicklung bis zur Auslieferung an den 
Kunden - begriffen. Es handelt sich also um ein neues systemisches Verständnis 
der Entwicklung. 


3.6.3 Der Einführungsprozess von Lean 


Der Bereich hat Lean Ende der 2000er Jahre auf Initiative des oberen und mittle- 
ren Managements in einem Pilotprojekt eingeführt und nach dem Erfolg dieses 
Pilotprojekts »top-down« flächendeckend ausgerollt. Zum Zeitpunkt der Unter- 
suchung war die formale Einführung von Lean abgeschlossen, und der Bereich 
stand vor der nächsten Entwicklungsherausforderung: Wie kann Lean nach der 
formalen Einführung wirklich »zum Fliegen« gebracht und zum Motor einer 
neuen Arbeitsorganisation gemacht werden? 


Pilotierung von Lean 

Das 2010 in Leben gerufene Pilot- bzw. Erprobungsprojekt war ein reines Soft- 
ware-Entwicklungsprojekt mit mehreren Hundert Mitarbeitern, die, global ver- 
teilt, an drei Standorten arbeiteten. Zentrales Ziel des Managements war es, 
Lean auf der »grünen Wiese« und »revolutionär« auszuprobieren. Das Projekt 
hatte den Auftrag, in Zusammenarbeit mit einem Beratungsunternehmen, das 
auch schon in einem anderen großen IT-Konzern Erfahrungen mit der Einfüh- 
rung von Lean in der Software-Entwicklung gesammelt hatte, ein Konzept zu 
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erarbeiten, das im Falle des Erfolgs im Bereich flächendeckend ausgerollt wer- 
den sollte. Das Projekt genoss mehrere Sonderrechte, die für das Verständnis 
des weiteren Entwicklungsverlaufs wichtig sind. Erstens wurde es vom oberen 
Management protegiert, vom Tagesgeschäft freigestellt und konnte sich auf die 
Neuorientierung konzentrieren. Zweitens wurden die Mitarbeiter des Projekts 
aktiv an der Entwicklung des Lean-Konzepts beteiligt, um dieses den spezifi- 
schen Gegebenheiten des Bereichs anzupassen. Sie hatten damit Freiräume, ihre 
Arbeit selbst zu gestalten. Dazu kam, dass die Mitarbeiter hoch motiviert waren 
und sich für die Neuorganisation der Entwicklung durch Lean begeisterten. In 
der Folge wurde das Projekt als Leuchtturm-Beispiel im gesamten Bereich be- 
kannt, und es gelang ihm, sich zum Vorreiter zu entwickeln. Diese positive Er- 
fahrung überzeugte die Führungskräfte, Lean flächendeckend auszurollen. 

In der Folge wurde überdies ein zweites Pilotprojekt initiiert, das sowohl die 
Entwicklung von Hardware als auch die Entwicklung von Embedded Software 
umfasste. Dieses Projekt hatte eine andere Ausgangskonstellation. Es genoss kei- 
ne vergleichbare Aufmerksamkeit des Managements und nicht dieselben Son- 
derrechte und Freiräume. Gleichzeitig gestaltete sich der Zugang der Entwickler 
zu Lean schwieriger als in dem reinen Software-Entwicklungsprojekt. Da das 
Modell lediglich übertragen wurde und die Entwickler nicht selbst an der Aus- 
gestaltung beteiligt waren, erlebten sie dieses als etwas »Fremdes«. Einer unserer 
Interviewpartner beschreibt diese Erfahrung folgendermaßen: 


»Und in [Pilotprojekt I], das war glaube ich eine ziemliche Erfolgsstory, während in 
[Pilotprojekt II] gerade durch die Besonderheit »Embedded Software/Hardware< die 
Spielregeln einfach vielleicht ein bisschen anders sind. Und ich denke mal, die Akzep- 
tanz bei den Leuten war nicht so gegeben. Also die Stimmung in der Mannschaft war 
zum damaligen Zeitpunkt: Warum sagen uns denn jetzt so Softwarehansis, wie wir 
jetzt hier arbeiten sollen? Die haben doch gar keine Ahnung, was wir hier eigentlich 
machen.« (F-64) 


Der Mangel an Beteiligung im zweiten Pilotprojekt führte auch zu einer ins- 
gesamt kritischeren Stimmung der Beschäftigten gegenüber dem neuen Modell. 
Auch wenn dort also nicht nahtlos an die positiven Erfahrungen des Vorgänger- 
projekts angeknüpft werden konnte, beschloss man nun, Lean in der Folge auf 
Grundlage des im ersten Pilotprojekt erarbeiteten Konzepts flächendeckend in 
der Entwicklung einzusetzen. 


Flächendeckende Lean-Einführung 


Die Einführungsstrategie war von drei Grundsätzen geprägt: Jedes neu aufge- 
legte Projekt war verpflichtet, Lean einzuführen; die Projektteams wurden zu 
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Beginn in einem Lean-Training mit dem neuen Organisationsmodell vertraut ge- 
macht; und jedes Projekt sollte seine Erfahrungen mit Lean sammeln und diese 
in eigens hierfür initiierten Treffen teilen. Das Ziel war, das Pilotmodell durch 
kontinuierlichen Austausch zu verfeinern. 

Um diesen Wandel in Richtung Lean Development zu unterstützen, wurde 
das sog. »Continuous-Improvement-Projekt« gegründet. Grundlage ist hier eine 
»Process Map«, die sich aus verschiedenen Domänen zusammensetzt, die im 
Laufe eines Entwicklungszyklus durchlaufen werden und die wiederum be- 
stimmte Meilensteine umfassen. Ziel ist es, die Prozessabläufe kontinuierlich 
zu verbessern. Hierfür tragen Qualitätsmanager, die in den Projekten für die 
Einhaltung der Prozesse zuständig sind, und »Lean Coaches« die Bedarfe und 
Änderungsvorschläge aus den einzelnen Projekten zusammen. Entscheidend ist 
dabei, dass dieses Projekt nicht im »Elfenbeinturm« stattfindet, sondern infolge 
der Mitarbeit der Qualitätsmanager und der »Lean Coaches« sehr nahe an den 
Projekten angesiedelt ist. Die Bedeutung des Projekts zeigt sich an den Karriere- 
schritten der Mitglieder. Es gilt als Sprungbrett zu wichtigen Führungspositio- 
nen. Dies hat den zusätzlichen Effekt, dass Schlüsselpositionen von Beschäftig- 
ten besetzt werden, die Lean ernst nehmen und konsequent vorantreiben. 

Die formale Implementierung des Lean-Konzepts war, so der Tenor bei den 
Führungskräften, relativ einfach. Inhaltlich gehe es jetzt darum, einen konti- 
nuierlichen Verbesserungsprozess zu etablieren, sich zu einer »selbstlernenden 
Organisation« zu entwickeln und die mit dem bürokratischen Prozessmodell 
verbundene Praxis abzulösen. In der aktuellen Phase befindet sich der Bereich 
auf der Suche nach den Erfolgsfaktoren, die dafür ausschlaggebend sind, das 
Entwicklungsziel zu erreichen und die hierfür nötige Dynamik in der Organi- 
sation zu entfachen. 


3.6.4 Lean als neues ganzheitliches Entwicklungsmodell 


Das neue Entwicklungsmodell kann durch fünf Dimensionen charakterisiert 
werden: kurzzyklische Taktung und Synchronisierung der Wertschöpfungsket- 
ten, Backlog als Basis für die arbeitsteilige Entwicklung, systemische Integration 
der Wertschöpfungsketten, Empowerment des Teams, Einführung neuer Lean- 
Rollen. Dabei beziehen sich die ersten drei Dimensionen auf die systemische 
Organisation der Entwicklung, die anderen beiden speziell auf die neue Rolle 
von Entwicklern und Führungskräften im neuen Entwicklungsmodell. 
Kurzzyklische Taktung und Synchronisierung der Wertschöpfungsket- 
ten: Die Basis von Lean ist die Organisation der Entwicklerteams als Teil einer 
kurzzyklisch getakteten und synchronisierten Wertschöpfungskette. In sechs- 
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monatigen Release-Zyklen, die wiederum in vierwöchige Sprints unterteilt sind, 
werden qualitativ geprüfte und verwendbare Produkte entwickelt. Das Ziel ist es, 
regelmäßig nach sechs Monaten ein neues Release an den Kunden auszuliefern. 

Die einzelnen Entwicklerteams »schwingen« nun als Teil der Wertschöp- 
fungskette im selben Takt. Die einzelnen Beiträge der Entwicklerteams werden 
im Idealfall kontinuierlich, spätestens aber am Ende des Sprints integriert. Pla- 
nung, Entwicklung und Integration sind eng miteinander verzahnt. Damit ge- 
winnt das frühzeitige und parallele Testen an Bedeutung. Bereits zum Entwick- 
lungsstart werden die Tests definiert und so systematisch in die Entwicklung 
eingelassen. Dadurch soll die Kompatibilität der verschiedenen Teilprodukte 
schon in einem frühen Entwicklungsstadium sichergestellt werden. 

Durch dieses Vorgehen soll erreicht werden, dass die einzelnen Entwickler- 
teams sich synchron auf das Release-Ende hin bewegen. Jeweils am Ende des 
Sprints wird deutlich, wo die einzelnen Teams stehen. Damit können die unter- 
schiedlichen Geschwindigkeiten in einer neuen Qualität austariert werden: 


»Dadurch, dass wir die Release ja synchron für alle machen, ist es meine Aufgabe, dafür 
zu sorgen, dass alle so synchron arbeiten, dass wir am Ende auch gemeinsam über die 
Ziellinie laufen. Was wir auch im Sinne dieses Taktens versuchen zu erreichen, ist, dass 
es möglichst niemanden gibt, der ganz weit vorne ist und andere sind ganz weit hinten. 
Sondern wir müssen einfach immer gucken, dass wir parallel über die Ziellinie kom- 
men. Und das ist dann schon auch eine Herausforderung.« (F-72) 


Durch Synchronisierung soll also sichergestellt werden, dass das Produkt am 
Ende des Release-Zyklus termingetreu an den Kunden ausgeliefert werden kann. 

Backlog als Basis für die arbeitsteilige Entwicklung: Die Grundlage 
für die Organisation der Arbeit mehrerer Entwicklerteams, die gemeinsam an 
einem komplexen Produkt arbeiten, ist der Release-Backlog, eine priorisierte Li- 
ste von Requirements. Er wird vor Beginn des Release vom Produktmanage- 
ment, einer eigenen Organisationseinheit, festgelegt. Dabei gilt das Prinzip, dass 
er über das Release hinweg stabil bleiben und nicht verändert werden soll. Der 
Release-Backlog wird auf die einzelnen Entwicklerteams verteilt, die bestimmte 
Komponenten des zu entwickelnden Produkts verantworten. 

Auf Basis des Release-Backlogs können selbst große und komplexe Entwick- 
lungsprojekte arbeitsteilig bearbeitet werden, ohne dabei die Spezifikation, die 
Architektur und die Erstellung systematisch und zeitlich voneinander zu tren- 
nen. Jeweils vor dem Sprint erfolgen die Priorisierung der Backlog-Items und die 
Erstellung der User Stories. Letztere umfassen die Use Cases, die Architekturideen 
und die Akzeptanzkriterien für den Test. Grundsätzlich wird die Regel verfolgt, 
dass die User Stories nur für zwei Sprints im Voraus erstellt werden. Dadurch 
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sei es nach Auskunft unserer Interviewpartner möglich, vor Beginn des Sprints 
ohne Verluste zu priorisieren. Es ergäben sich weniger »Reibungsverluste«, und 
waste werde vermieden, da noch keine Arbeit in das Arbeitspaket investiert wur- 
de. Darüber hinaus sei die Entwicklung dadurch »agiler«. 

Systemische Integration der Wertschöpfungsketten: Sie ist bei der arbeits- 
teiligen Bearbeitung großer und komplexer Entwicklungsprojekte von zentraler 
Bedeutung. Sie wird im Fallunternehmen - neben der synchronen Taktung - 
durch zwei komplementäre Ebenen organisiert: durch eine IT-gestützte Platt- 
form, mittels derer die Arbeit strukturiert wird, und durch eine neue Qualität 
der Kommunikation und Kollaboration in den Teams. 

Die Funktionsweise der IT-Plattform entspricht dem aus Fall E bekannten 
Modell, auch die Software-Basis (RTC) ist die gleiche. Die Teams ziehen die Auf- 
gaben von oben aus dem Backlog, der hier verwaltet wird, bearbeiten sie und 
halten den Bearbeitungsstatus fest. Das Ziel ist, dass am Ende des Sprints alle 
verpflichtenden »mandatory«) Requirements bearbeitet sind. Die zusätzlich 
angegebenen optionalen Requirements stellen die sog. »Atemmasse« dar. Der 
Arbeitsstand der Entwicklerteams ist jederzeit einsehbar. 

Komplementär dazu wurden Institutionen eingeführt, die eine neue Quali- 
tät der Kommunikation und Kollaboration ermöglichen und sowohl dem Wis- 
sensaustausch als auch der kontinuierlichen Kalibrierung der Aufgaben dienen. 
Die Entwicklerteams treffen sich regelmäßig zum Daily Scrum und tauschen 
sich hier über ihren Arbeitsstand aus. Während auf der RTC-Plattform ledig- 
lich der Arbeitsstand einsehbar ist, werden auf diesen Treffen die Aufgaben mit 
Inhalt gefüllt und das notwendige Kontextwissen wird ausgetauscht. So ist auf 
der Plattform z.B. erkennbar, dass eine Aufgabe bereits schr lange bearbeitet 
wird, aber nicht, warum oder welche Schwierigkeiten damit verbunden sind. 
Die Treffen finden nicht nur auf Teamebene statt, sondern werden kaskadiert, 
um die verschiedenen Entwicklerteams zu koordinieren. Hierfür treffen sich 
die Vertreter der Teams regelmäßig mit dem Projektleiter und dem Produkt- 
management, um sich über den Arbeitsstand der Teams auszutauschen. Damit 
kann der Arbeitsfortschritt der Teams kontinuierlich evaluiert werden. 

Mittels dieser komplementären Elemente der Arbeitsorganisation wird die 
systemische Integration und Synchronisierung der Wertschöpfungsketten kon- 
tinuierlich hergestellt. Indem durch die IT-Plattform und durch persönlichen 
Austausch Transparenz geschaffen wird, ist der Entwicklungsprozess — früher 
eine »Black Box« - nunmehr nachvollziehbar, wobei durch die regelmäßigen 
Treffen sowohl auf Team- als auch auf Ebene der Führungspersonen auch ein 
inhaltlicher Kontext geschaffen wird. Dadurch wird es für Führungskräfte mög- 
lich, in neuer Qualität steuernd in den Entwicklungsprozess einzugreifen. 
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Empowertes Team als Nukleus der neuen Arbeitsorganisation: Zentra- 
le Einheit der Organisation von Arbeit ist nicht mehr der einzelne Entwickler, 
sondern ein Kollektiv aus Entwicklern. Damit vollzieht sich ein Paradigmen- 
wechsel vom bürokratischen Expertenmodus hin zur Konstituierung eines Kol- 
lektivteams. Das Ziel ist, dass das Team zusammenwächst und sich die Wissens- 
domänen der einzelnen Entwickler zunehmend überlappen. Das Team ist eine 
autonome Einheit, die innerhalb der Sprints über hohe Gestaltungsspielräume 
in der Organisation ihrer Arbeit verfügt und sich selbst organisiert. Es bestimmt 
den Workload - manche Teams können sogar über die Inhalte entscheiden - und 
verantwortet innerhalb des Sprints die Bearbeitung des Backlogs eigenständig. 

Vom Entwicklerteam wird - wie es in einem Interview heißt — erwartet, eine 
früher verbreitete »Checklistenmentalität« abzulegen und sich nicht einfach an 
Prozessvorgaben zu halten, sondern eine »aktive Rolle« zu spielen (F-64). Dies 
betrifft die Sprintplanung, aber auch die kontinuierliche Verbesserung der be- 
stehenden Prozesse. Das empowerte Kollektivteam ist damit der Ausgangspunkt 
für das kontinuierliche Lernen der Organisation. Insbesondere mit Blick auf 
das Empowerment der Teams zeigen sich in der Praxis enorme Unterschiede. 
Dies betrifft sowohl die Konstituierung der Teams als Kollektiv als auch deren 
Empowerment. Dieser Aspekt wird unten im Vergleich der unterschiedlichen 
Entwicklungsstadien der Teams noch vertieft. 

Lean-Rollen und die Veränderung von Aushandlungsstrukturen: Im 
Kontext von Lean wurden neue Rollen wie die des Product Owners und des Scrum 
Masters eingeführt, die sich auf die bestehende Führungskultur auswirken. Dies 
geschah unter Beibehaltung der bestehenden Führungsstruktur, die konzern- 
weit von der HR-Abteilung vorgegeben ist. Daraus ergibt sich eine komplexe 
Gemengelage, denn die Lean-Rollen wurden mit der bestehenden Struktur ver- 
koppelt, ohne die sich daraus ergebenden Widersprüche und Konflikte systema- 
tisch aufzulösen. Die mit Lean einhergehende Veränderung von Führung ist ein 
brisantes und offenes Thema, das noch nicht abschließend bearbeitet wurde. 
Gleichzeitig impliziert der gewählte Weg, dass die Bearbeitung der Konflikte, 
die sich aus der komplementären Einführung der Lean-Rollen ergeben, in die 
Arbeitspraxis verlagert wird. 

Da die Entwicklung und das Produktmanagement zwei eigenständige Or- 
ganisationseinheiten sind, wird die Product-Owner-Rolle gemeinsam vom Pro- 
jektleiter und dem Produktmanagement übernommen. Damit wurden bereits 
bestehende Rollen einfach umbenannt und der Rolleninhalt im Sinne des Lean- 
Prozesses bestimmt. Demzufolge bestimmt das Produktmanagement den Re- 
lease-Backlog, und der Projektleiter ist für die Organisation der Arbeit im Team 
verantwortlich. Zusätzlich wurde die Rolle des Scrum Masters eingeführt. Er ist 
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Teil des Teams und dessen »Sprachrohr«. Er vertritt einerseits das Team nach 
außen und ist andererseits dafür verantwortlich, den Lean-Prozess im Team vo- 
ranzutreiben. 

Aus dieser neuen Rollenkonstellation zwischen Product Owner, Team und 
Scrum Master ergeben sich neue Aushandlungsstrukturen, die in der Praxis per- 
manent bearbeitet werden müssen. Die produktive Bearbeitung des Spannungs- 
verhältnisses zwischen den Rollen ist für das Gelingen von Lean fundamental. 
Hervorgehobene Bedeutung hat in den Aushandlungen die Product-Owner-Rol- 
le. Die entscheidende Frage ist dabei, ob der Projektleiter und das Produktma- 
nagement »an einem Strang ziehen« und das Empowerment des Teams ernst 
nehmen. Erfolgreiche Lean-Teams - dies soll unten noch gezeigt werden - zeich- 
nen sich dadurch aus, dass sich das Team selbst organisiert und der Product 
Owner den vom Team bestimmten Workload respektiert. Demgegenüber wird 
in weniger erfolgreichen Teams das Empowerment durch direkte Intervention 
permanent unterminiert. Diese Spannung zwischen Empowerment des Teams 
und direkter Intervention muss permanent austariert werden. Dabei darf die 
Rolle des Scrum Masters nicht unterschätzt werden. 


3.6.5 Entwicklungsstadien der Lean-Teams 


In der Praxis zeigen sich große Entwicklungsunterschiede zwischen unterschied- 
lichen Projekten und Teams. Sie resultieren einerseits aus den unterschiedlichen 
Einführungszeitpunkten. Einige Projekte haben Lean bereits vor vier Jahren 
eingeführt, während in anderen Projekten die Einführung erst ein halbes Jahr 
zurückliegt. Andererseits zeigen sich Unterschiede zwischen der Hardware-, 
der Embedded-Software- und der reinen Software-Entwicklung. In der reinen 
Software-Entwicklung ist Lean angekommen, während sich die Hardware- und 
die Embedded-Software-Entwicklung nach wie vor schwer tun, Lean auf ihren 
Arbeitsbereich zu übertragen. Insgesamt haben es bislang nur wenige Vorreiter- 
Teams geschafft, Lean in eine neue »gelebte Praxis« zu übersetzen. Dagegen ist in 
anderen Teams unter der Oberfläche nach wie vor die bürokratische Arbeitskul- 
tur prägend. Wichtige Dimensionen, die hierbei in der Praxis ausschlaggebend 
sind, sind das Empowerment der Teams, die Ausübung von Führung im Kontext 
neuer Rollen und die damit einhergehende Veränderung des Machtgefüges. 
Um die Entwicklungsunterschiede der Teams im Fallunternehmen in den 
Blick zu nehmen, erweist sich die Unterscheidung zwischen der bloß formalen 
Einführung des Lean-Prozesses und einem Status, in dem Lean wirklich zur ge- 
lebten Praxis wird, als äußerst instruktiv. In unserer Untersuchung konnten wir 
drei Entwicklungsstadien unterscheiden: Erstens Teams, die das neue Organisa- 
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tionsmodell anhand von konkreten Methoden und Tools zwar konsequent an- 
wenden, aber nur formal umsetzen, während unter der Oberfläche vieles beim 
Alten bleibt und die bürokratische Kultur nach wie vor bestimmend ist (For- 
male Lean-Teams, vgl. Kapitel 3.6.5.1). Zweitens Teams, die es geschafft haben, 
sich zu Vorreiter-Teams zu entwickeln (Kapitel 3.6.5.2). Schließlich Teams, die 
sich regelrecht in einem permanenten Krisenmodus befinden. Sie haben Lean 
eingeführt und sind den damit einhergehenden erhöhten Anforderungen ausge- 
setzt, während jedoch Potenziale von Lean, die der Entlastung dienen könnten, 
fortwährend unterminiert werden. Charakteristisch für diese Teams sind daher 
meist hohe Belastungen in der Arbeit (Kapitel 3.6.5.3). 


3.6.5.1 Formale Lean-Teams 

Das Entwicklungsstadium des formalen Lean-Teams umfasst die erste Phase 
nach der Lean-Einführung und wird von allen Teams durchlaufen. Die Teams 
erproben das neue Organisationsmodell, aber die Einführung von Lean ist noch 
zu neu, als dass sich schon merkliche Veränderungen in der gelebten Praxis zei- 
gen könnten. Zentrales Moment dieser Phase ist ein komplexer sozialer Ausei- 
nandersetzungsprozess der Beschäftigten und Führungskräfte mit Lean, der für 
die weitere Entwicklung von großer Bedeutung ist. 

Die Arbeitsorganisation des Teams wird hier zunächst nach den in Kapi- 
tel 3.6.4 beschriebenen Maßgaben neu strukturiert. In dieser Phase erscheint 
es fast selbstverständlich, dass die Teams häufig noch im Geiste des bürokrati- 
schen Prozessmodells arbeiten. So setzte beispielsweise ein Team die vorgegebe- 
nen Institutionen zwar um, indem es seinen Backlog plante, schätzte und seine 
Arbeit über die RTC-Plattform organisierte. Bei genauerem Hinsehen zeigte sich 
jedoch, dass die Organisation tatsächlich nach wie vor auf einer a priori fest- 
gelegten sequenziellen Meilensteinplanung basierte, die in einem Excel-Sheet 
festgehalten und dann sukzessive auf die RTC-Plattform übertragen wurde. In 
einem anderen Beispiel war das Lean-Team zwar neu zusammengesetzt worden, 
um gemeinsam an Aufgaben zu arbeiten, aber in der Praxis agierten die Team- 
mitglieder weitgehend als »Einzelexperten«. Die Arbeitspakete wurden dann 
sehr groß dimensioniert und so angelegt, dass sie nur von bestimmten Einzel- 
experten bearbeitet werden konnten. Nach und nach zeigen sich dann meist 
erste Ansätze, wie die Lean-Institutionen als Hebel für die Veränderung der Zu- 
sammenarbeit genutzt werden können. Meistens spielt das Daily Scrum eine ent- 
scheidende Rolle. Die Teammitglieder nutzen es, um sich auszutauschen und 
einander zu helfen. 

Entscheidend ist in dieser Phase, dass das Team die Institutionen versteht. 
Dies ist die Voraussetzung, so eine Interviewperson, für den nächsten Schritt: 
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»Wo ich jetzt stehe, ist, dass ich im Prinzip die Infrastruktur so vorbereitet habe, dass 
wir diesen Approach auch leben können. [...] Das heißt, die Methodik, grob gespro- 
chen, ist verstanden. Jetzt kommen wir eigentlich in den nächsten Schritt, dass wir 
diese Methodik leben wollen. Das klappt bei dem einen Kollegen besser als bei dem 
anderen.« (F-55) 


Die Teams setzen sich in der Folge intensiv mit der neuen Organisationsform 
von Arbeit auseinander. Sowohl Beschäftigte als auch Führungskräfte stellen 
sich die Frage, welche Bedeutung Lean für den eigenen Arbeitsbereich hat und 
ob die Einführung von Lean ein Schritt in die richtige Richtung ist. Dieser Pro- 
zess verläuft in den verschiedenen Teams mit unterschiedlicher Geschwindigkeit 
und unterschiedlichem Ergebnis. In unserer Untersuchung zeigte sich, dass für 
die Analyse des Auseinandersetzungsprozesses drei Faktoren relevant sind: die 
Art des Einführungsprozesses, die historisch gewachsenen Arbeitskulturen und 
die strukturellen Rahmenbedingungen. 

Bei der Art des Einführungsprozesses kommt der Beteiligung der Beschäftig- 
ten zentrale Bedeutung zu. Teams, die bereits zu Beginn eingebunden werden 
und an der Gestaltung des Konzepts beteiligt sind, nehmen Lean cher als neues 
Organisationsmodell an und sind eher bereit, es aus Eigeninitiative voranzutrei- 
ben. Deutlich wird dies insbesondere beim Vergleich der beiden oben erwähn- 
ten Pilotprojekte. Während die Beschäftigten beim ersten Pilotprojekt an der 
Einführung des neuen Organisationsmodells beteiligt waren und Handlungs- 
spielräume hatten, um das Konzept an die eigene Arbeit anzupassen, wurde das 
Modell im zweiten Pilotprojekt ohne Anpassung und ohne eigene Gestaltungs- 
möglichkeiten umgesetzt. Gerade die Übertragung des Konzepts von der Soft- 
ware- auf die Hardware-Entwicklung - ohne Beteiligung der Entwickler - stieß 
auf Widerstand. Lean wurde als etwas Fremdes begriffen. Während das erste 
Team begann, Lean aus sich heraus voranzutreiben, verlor die Einführung im 
zweiten Projekt schnell an Dynamik. 

In Hinsicht auf die historisch gewachsenen Arbeitskulturen spielt die Experten- 
kultur, die in der bürokratischen Organisation entstanden ist, eine Hauptrolle. 
Das Leitbild des individualistischen Experten ist in diesem Bereich stark aus- 
geprägt. Die in Lean angelegte Überführung des Einzel-Experten in einen Kol- 
lektiv-Experten erweist sich als eines der schwierigsten Momente der Lean-Ein- 
führung. Oft besteht der Einzel-Expertenmodus unter der Oberfläche fort und 
wird von den Beschäftigten verteidigt. Dies hat auch historische Gründe, denn 
Lean wird nicht auf der »grünen Wiese« eingeführt, sondern in Projekten, in 
denen die einzelnen Mitglieder bestimmte Themenfelder abdecken, auf denen 
sie sich im Lauf der Zeit tiefe Kenntnisse angeeignet haben. Entsprechend wird 
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es häufig als naheliegend begriffen, dass der ausgewiesene Experte die Aufgabe 
bearbeitet. Darüber hinaus steckt dahinter die Vorstellung, etwas Eigenes zu 
haben. So erklärt uns ein Projektleiter: »Man muss auch ein bisschen sagen, das 
ist mein Baby.« 

Vor dem Hintergrund dieser Darstellung wird deutlich, warum bei der Lean- 
Einführung strukturelle Rahmenbedingungen wie Vertrauen und Sicherheit von 
zentraler Bedeutung sind. Das Vertrauen in das Team ist eine wesentliche Vo- 
raussetzung für die Entwicklung des Teams zum empowerten Kollektivteam. 
Während Teams, denen vertraut wird, sich selbst organisieren und sich zum ler- 
nenden Team entwickeln können, wird die Basis von Lean in Teams, in denen 
Führungskräfte permanent intervenieren, unterminiert. Gerade in der Anfangs- 
zeit ist das Vertrauen in das Team maßgeblich für den Entwicklungsweg. 


3.6.5.2 Vorreiter-Teams 

Unter den von uns untersuchten Teams haben die Vorreiter-Teams das Stadium 
des formalen Lean-Teams überwunden und es geschafft, die zentralen Institu- 
tionen von Lean gleichsam mit Leben zu erfüllen und eine neue Qualität der 
Zusammenarbeit zu etablieren. Von diesen Teams kann gelernt werden, wie 
Lean funktioniert, wenn z.B. erste »Kinderkrankheiten« überwunden sind. Ins- 
besondere an der Perspektive der Beschäftigten wird deutlich, wie durch die 
konsequente Umsetzung von Lean eine positiv erlebte Arbeitskultur geschaffen 
werden kann. 

Die Entwicklung von der bloß formalen Lean-Einführung bis zur Etablie- 
rung einer neuen Arbeitskultur erstreckt sich über mehrere Jahre. Nach der 
Einschätzung der Vorreiter-Projekte dauert es »ein, zwei Jahre, bis so die ersten 
kleinen Blüten zu sehen sind«, und vier Jahre, bis aus der Sicht des Managements 
die Erfolge in Bezug auf Zuverlässigkeit und Qualität sichtbar werden: 


»Bis wir in den jetzigen Zustand gekommen sind, wo wir die letzten zwei Releases vor 
Termin fertigstellen konnten, eine Qualität haben, die wir noch nie vorher hatten, also 
Superqualität, läuft also momentan alles am Schnürchen - Aber bis zu dem Zeitpunkt, 
würde ich sagen, vier Jahre locker, ne? Also es war schon ein steiniger Weg, dorthin zu 
kommen, und Gott sei Dank haben wir die ersten Misserfolge nicht auf diese Vorge- 
hensweise geschoben .« (F-79) 


Vier Eigenschaften sind für die Art und Weise der Zusammenarbeit von Vorrei- 
ter-Teams charakteristisch: die Entwicklung vom formalen Lean-Team zum Kol- 
lektivteam; das Empowerment des Teams; der Umstand, dass die neuen Rollen 
im Sinne von Lean »gelebt« werden; und die Tatsache, dass Lean als kontinuier- 
licher Verbesserungsprozess praktiziert wird. 
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Entwicklung vom formalen Lean-Team zum Kollektivteam: Die Team- 
mitglieder sind über die Jahre hinweg zusammengewachsen und begreifen sich 
als stabiles Team. Die Experten arbeiten nicht mehr allein in ihren »Silos«, und 
durch die kontinuierliche Zusammenarbeit überlappen sich ihre Wissensdomä- 
nen zunehmend. Die Basis einer solchen Entwicklung hin zum Kollektivteam 
sind die Lean-Institutionen, die aktiv für die Zusammenarbeit und den Aus- 
tausch von Wissen genutzt werden. Durch die gemeinsame Planung anhand des 
Backlogs und die Organisation der Arbeitsteilung auf der RTC-Plattform wird 
eine neue Transparenz geschaffen. Darüber hinaus wird das Daily Scrum als zen- 
trale Institution des Austauschs aktiv genutzt. Insbesondere ihm wird in den 
Interviews eine zentrale Bedeutung zugewiesen: 


»Also ich glaub, der entscheidende Unterschied ist, dass man miteinander redet. Man 
schafft eine gewisse Transparenz durch das, dass man jeden Tag zusammen steht, dass 
man jeden Tag darüber spricht und, wie gesagt, in diesem Stand-up, wenn ich dann 
merke, ein Kollege hat ein Problem, dann wird geholfen.« (F-73) 


Früher, so der Tenor in den Interviews, haben die Entwickler viel mehr allein 
gearbeitet. Dies habe sich durch die Einführung von Lean geändert. So wird 
festgestellt, dass 


»die Arbeit im Team intensiver geworden ist oder besser, die Zusammenarbeit unter 
den Entwicklern, also dieses tatsächliche Interagieren. Also es ist anders, also es gibt 
nicht mehr die Leute, die jetzt sich irgendwas vornehmen und so still vor sich hin ha- 
cken, sondern das, glaube ich, ist erheblich besser geworden durch diesen Austausch, 
den man da ständig hat.« (F-75) 


Durch das aktive Nutzen der Lean-Institutionen sind die Teams zusammenge- 
wachsen; trotz allem ist die Überwindung des individualistischen Expertenmo- 
dus nicht abgeschlossen. In den Interviews wird immer wieder erwähnt, dass die 
Entwickler häufig in den alten Modus zurückfallen. Nicht zuletzt aus arbeits- 
ökonomischen Gründen liege es häufig nahe, dass ein ausgewiesener Experte 
das Themenfeld bearbeite, denn ein anderer Mitarbeiter müsste sich erst in das 
Thema einarbeiten. Hier wird ein Zusammenhang mit strukturellen Bedingun- 
gen sichtbar, denn die Kollektivierung von Wissen erfordert Zeitressourcen, die 
unter gegebenem Marktdruck oft nicht vorhanden sind. 

Empowerment des Teams: Zentrales Charakteristikum der Vorreiter-Teams 
ist, dass sie als autonome Einheit empowert sind. Sie verfügen in ihrer täglichen 
Arbeit über hohe Gestaltungsspielräume, bestimmen über den Workload und 
manchmal sogar über den Inhalt und übernehmen selbst die Verantwortung für 
die Bearbeitung. Die Basis für das Empowerment schaffen die zentralen Institu- 
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tionen und Routinen des neuen Entwicklungsmodells, indem die Teams ausge- 
hend vom Release-Backlog den Workload des Release und jeweils vor Beginn des 
Sprints den Workload des Sprint-Backlog schätzen - und zwar kollektiv. In den 
Interviews wird immer wieder betont, dass es nicht darum gehe, einen Mittel- 
wert zu bilden, sondern Abweichungen zu diskutieren und zu einer Einigung 
zu kommen. Das Ziel ist, dass das Team als Kollektiv den Backlog verantwortet 
($»commitet«): Es übernimmt die Verantwortung, alle festgelegten Aufgaben des 
Backlogs zu bearbeiten. 

Was es im Einzelnen bedeutet, Empowerment des Teams wirklich zu »le- 
ben«, lässt sich gut an dem Verfahren illustrieren, wie innerhalb eines Sprints 
mit Störungen umgegangen wird. Grundsätzlich gilt die Regel, dass der Backlog 
im Sprint unangetastet bleibt. Falls dennoch eine Ausnahmesituation eintreten 
sollte - wenn etwa eine wichtige Kundenanforderung auftritt oder Entwickler 
sich verschätzt haben -, dann wird in empowerten Teams gemeinsam mit dem 
Product Owner und dem Produktmanagement eine neue vertretbare Lösung ge- 
sucht, in die die neuen Umstände aufgenommen werden. Empowerment ist hier 
kein einmaliger Abstimmungsakt zu Beginn des Sprints, sondern Teilmoment der 
Beziehung zwischen Team, Product Owner und Produktmanagement. Entschei- 
dend ist, dass der Product Owner und das Produktmanagement die Selbstorganisa- 
tion des Teams, dessen Planung und Schätzung ernst nehmen und respektieren. 

Aus unserer Untersuchung geht hervor, dass das Empowerment als der in- 
nere Kern der neuen Arbeitskultur verstanden wird. Ein Entwickler bringt dies 
folgendermaßen zum Ausdruck: 


»Das [Empowerment] spielt bei uns eine wichtige Rolle. [...] Wenn wir das Gefühl ha- 
ben, oder wenn ein Entwickler das Gefühl hat, oder allgemein, wenn ein Mensch das 
Gefühl hat, er kann selbst entscheiden und er kann [seine Arbeit] selbst zu Ende brin- 
gen, ohne dass er ständig kontrolliert wird.« (F-73) 


Diese Art der Selbstorganisation wird als Gegensatz zur permanenten Kontrol- 
le durch Führungskräfte betrachtet. Dementsprechend ist das Vertrauen in das 
Team von entscheidender Bedeutung: 


»Vertrauen ist das A und O. Wenn ich was rein geb: vier Wochen, vertraue ich dem 
Team, dass es das macht.« (Ebd.) 


Sowohl die Entwickler als auch die Führungskräfte sind sich einig, dass das Ver- 
trauen gegeben ist und dies ein wesentlicher Baustein ihres Erfolgs ist. Das Em- 
powerment ist der entscheidende Baustein dafür, dass die Entwicklerteams Lean 
positiv erleben. 
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In der Praxis wird zudem deutlich, dass das Empowerment der Ausgangs- 
punkt für das kontinuierliche Lernen ist. Das zeigt sich besonders beim Schät- 
zen. Normalerweise machen die Teams zu Beginn die Erfahrung, dass sie sich 
deutlich verschätzen. Mit der Zeit entwickeln sie ein genaueres Wissen über den 
Arbeitsgegenstand, aber auch über ihre Fähigkeiten. 


»Klar, die gewinnen auch an Erfahrung, muss man sagen. Und es ist gar keine so ein- 
fache Geschichte. Anhand eines Grobverständnisses einer bestimmten Funktionalität, 
die man in einem kurzen Rahmen von vielleicht einer Viertelstunde dargestellt hat: 
»Okay, das schätzen wir grob mit dem und dem Daumenwert. Das ist schon ein erheb- 
liches Maß an Wissen, das da zuschlagen muss, und das wird im Laufe der Zeit natür- 
lich besser. Also die Abweichungen am Anfang waren, denke ich, größer, als sie in der 
Zwischenzeit sind.« (F-83) 


Über die Jahre haben die Teams ihre Schätzung sukzessive verbessert. In der 
Folge feiern sie jetzt Erfolge bezüglich der Einhaltung des Termins und der Qua- 
litätsstandards. 

In Teams, die wir als Vorreiter-Teams kennengelernt haben, fällt auf, dass die 
neuen Lean-Rollen umgesetzt und »gelebt« werden und in der Folge produktive 
Aushandlungsprozesse zwischen den Beteiligten entstehen. Das Erfolgsgeheim- 
nis dabei ist, dass Projektleiter und Produktmanagement »an einem Strang zie- 
hen«. Auch der Scrum Master füllt seine Rolle im Sinne von Lean aus, indem er 
bei Problemen aktiv vermittelt und sich bei Bedarf um Unterstützung für das 
Team kümmert. 

Der Product Owner - also sowohl der Projektleiter als auch das Produktma- 
nagement - nimmt das Empowerment ernst, gibt dem Team Entscheidungsfrei- 
räume, respektiert dessen Einschätzung des Workloads und schenkt ihm Ver- 
trauen. In der Praxis zeigt sich dies daran, dass in den Sprint nicht interveniert 
wird. Sollten ausnahmsweise Veränderungen des Sprint Backlog erforderlich 
werden, wird, wie erwähnt, gemeinsam mit dem Team diskursiv eine Lösung 
gesucht. Gerade diese Nutzung der Lean-Institutionen, -Prinzipien und -Rollen 
für produktive Aushandlungsstrukturen ist ein zentrales Charakteristikum von 
Vorreiter-Teams. 

Die Vorreiter-Teams haben es geschafft, eine neue Kultur der Zusammen- 
arbeit zu etablieren, in der auch kontinuierliche Verbesserung ernst genommen 
wird. Auch wenn sie im Vergleich zu anderen Teams schon viel erreicht haben, 
ist dies für die Teams ein kontinuierlicher und offener Prozess. Die Teammit- 
glieder reflektieren die Gefahren des Rückfalls in »alte Muster« und denken über 
ihre Errungenschaften und Verbesserungsmöglichkeiten nach. 
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3.6.5.3 Teams in der Krise 

Lean-Teams, die es nicht geschafft haben, »ins Fliegen« zu kommen, geraten 
oft in einen Krisenmodus. Sie haben die Lean-Institutionen zwar formal ein- 
geführt und sind dem kurzzyklischen Lieferdruck ausgesetzt, befinden sich aber 
in einem permanenten Ausnahmezustand, der dazu führt, dass Lean kaum »ge- 
lebt« wird und immer wieder außer Kraft gesetzt wird. Dies resultiert entwe- 
der daraus, dass das Produkt noch instabil ist und mit den Folgeproblemen zu 
kämpfen hat, oder daraus, dass der Workload aus verschiedenen Gründen nicht 
bewältigt werden kann. In der Folge agieren die Teams in einem permanen- 
ten »Firefight-Modus«. Die Teams befinden sich damit konstant in einer dilem- 
matischen Situation, da einerseits die Grundprobleme gelöst werden müssten, 
dies aber andererseits mit Blick auf den Lieferdruck nicht angepackt werden 
kann. Dadurch sind die Teams enorm hohen Belastungen ausgesetzt, was sich in 
schlechter Stimmung und Unzufriedenheit der Beschäftigten äußert. 

Der permanente Krisenmodus kann durch vier Dimensionen charakterisiert 
werden: ständiger »Firefight-Modus«; Unterminierung der Stabilität der Teams; 
Lean ohne Empowerment; hohe Belastungen. 

Ständiger »Firefight-Modus«: Teams, deren Produkte noch instabil und 
fehleranfällig sind und die mit »Kinderkrankheiten« zu kämpfen haben, müs- 
sen sich häufig mit den unbewältigten Altlasten auseinandersetzen. In der Folge 
sind diese Teams zusätzlich zu den Anforderungen des Release mit einer extrem 
hohen Maintenance-Last konfrontiert, die meistens unerwartet auftritt und die 
Release-Planung gefährdet. Charakteristisch für diese Teams ist, dass sie sich in 
einem »permanenten Ausnahmezustand« erleben. Ein Teil des Teams wird dann 
nicht selten aus dem Release entlassen, um z.B. ungeplante Kundenanforderun- 
gen zu bearbeiten, während der andere Teil des Teams versucht, mit reduzier- 
tem Personal die Release-Planung zu bewältigen. In diesem Stadium werden 
die Lean-Institutionen aufgegeben, es wird eine alternative Planung erstellt und 
unter hohem Druck auf das kurzfristig zu erreichende Ziel hingearbeitet. Die 
Arbeit im »Firefight-Modus« führt dann in einen Teufelskreis, da Fehler unter 
Zeitdruck nicht systematisch behoben, sondern nur kurzfristig ausgebessert 
werden. Eine Interviewperson beschreibt diese Problematik folgendermaßen: 


»Wenn es drauf ankommt, dann [...] wird doch die Änderung schnell reingemacht, 
dann wird es doch nicht ausreichend getestet. Es wird irgendwo im System an allen 
Ecken rumgeschraubt und reingekippt und man weiß genau, da schlummern jetzt 
schon wieder die nächsten Probleme drin, und man kriegt selber aber nicht die Zeit, 
das einfach mal wirklich gut zu durchdenken, einen ausführlichen Test zu machen oder 
das noch mal umzubauen.« (F-58) 
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Diese Art der Krisenreaktion unterscheidet sich deutlich von Reaktionsformen 
in Vorreiter-Teams, bei denen nötigenfalls ein ganzer Release darauf verwendet 
wird, Fehler zu bereinigen, um die Altlasten zu bewältigen. Wenn die Fehler- 
quote zu hoch ist, wird das Prinzip »stop the line« angewendet und alle Ent- 
wickler beschäftigen sich nur mit der Fehlerbehebung, bis die Quote wieder ak- 
zeptabel ist. Damit kann der angedeutete »Teufelskreis« durchbrochen werden. 

Unterminierung der Stabilität der Teams: Ein Charakteristikum von Lean- 
Teams in der Krise ist die Instabilität der Teams und damit die Unterminierung 
eines Grundprinzips von Lean, nämlich Konstituierung des Teams als Nukleus 
des neuen Entwicklungsmodells. Die Stabilität des Teams ist die Voraussetzung 
für die Entwicklung zum Kollektivteam und das kontinuierliche Lernen. 

Die Instabilität der Teams resultiert einerseits aus dem permanenten »Fire- 
fight-Modus«. Häufig fehlen in den Teams zudem die Personalressourcen und 
bestimmte Experten zur Bewältigung der vorgegebenen Release-Ziele. Wenn 
sich andeutet, dass die Release-Ziele eines Teams gefährdet sind, werden ande- 
re Teams »auseinandergerissen«, indem Mitarbeiter und Freelancer ausgeliehen 
werden. Dabei entsteht eine komplizierte Gemengelage, denn es kann sein, 
dass ein anderes Team Experten verliehen hat und diese dann wiederum zur 
Bewältigung der eigenen Release-Ziele fehlen. Andererseits wird die Instabili- 
tät der Teams durch das Einzel-Expertentum befördert. Da bestimmte Themen 
nur ausgewählte Experten übernehmen können, werden diese immer von dem 
Team ausgeliehen, das sie am notwendigsten braucht. Die Ablösung des »Einzel- 
kämpfertums« ist deshalb entscheidend für eine Weiterentwicklung des Teams. 
Ein Projektleiter sagt es so: 


»Wir müssen konsequent daran arbeiten, weg von diesen Einzelkämpfern hin zu Teams 
zu kommen. Wir müssen Themen auf viele Schultern packen. Da müssen wir uns be- 
wusst hinentwickeln. Wir müssen uns also bewusst in Projekten entscheiden, diese 
beiden, drei Kollegen arbeiten jetzt in diesem Thema und wir wissen, es dauert, es 
ist langsamer, wir schaffen weniger, als wenn das jetzt einer der Spezialisten machen 
würde. Ist eine bewusste Entscheidung, die wir treffen müssen. Wo wir auch gegen den 
Marktdruck kämpfen müssen, den wir haben.« (F-54) 


In dieser Passage wird der Konflikt in den Teams deutlich. Einerseits agieren 
Teams, die sich in der Krise befinden, permanent unter Marktdruck, andererseits 
muss die Auflösung des Einzel-Expertentums gegen den Marktdruck durchge- 
setzt werden. 

Die Instabilität der Teams ist eine ausgeprägte Quelle von Unzufriedenheit 
und wird von den Beschäftigten stark kritisiert. Damit verstoßen die Führungs- 
kräfte, so eine Interviewperson, gegen eigene Versprechen: 
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»Also mit der Einführung von Lean gab es ja quasi das Versprechen dieses stabilen 
Teams, das an einem Standort sitzt, das zusammenarbeitet. Ich hatte das Gefühl, das 
war auch was, wo sich die Leute drauf gefreut haben. Endlich mal was Stabiles, was, 
worauf man sich verlassen kann, wo man planen kann. Und seitdem das jetzt so häufig 
stattfindet, mit dem »Leute aus Teams rausziehen, woanders reinziehen«, auch kurz- 
fristig, auch quasi mitten im Takt, wo es ja immer hieß, der Takt ist heilig, das ist was, 
wo man sich drauf verlassen kann, womit man planen kann - da wächst natürlich die 
Unzufriedenheit.« (F-68) 


Lean ohne Empowerment: In Lean-Teams, die sich in der Krise befinden, be- 
steht oft kein Empowerment mehr. Zwar werden die Lean-Institutionen formal 
praktiziert, aber in der Praxis immer wieder außer Kraft gesetzt. Die Teams sind 
damit den erhöhten Anforderungen in Lean ausgesetzt, ohne gleichzeitig von den 
vorgesehenen Schutzmechanismen profitieren zu können. Obwohl es die Teams 
selbst sind, die planen und schätzen, ist der Backlog oft überladen; es fehlen die 
»Puffer«, die Vorreiter-Teams eingeplant haben, um nicht sofort unter Druck zu 
geraten, wenn Unplanmäßiges geschieht. Bei einem von Beginn an überladenen 
Backlog spitzt sich die Lage sofort zu, sobald unerwartete Aufgaben »on top« erle- 
digt werden müssen. Dies wiederum geschieht oftmals dann, wenn der Projekt- 
leiter und das Produktmanagement in ihrer Rolle als Product Owner nach wie vor 
im bürokratischen Modus agieren und von außen in die Planung des Teams ein- 
greifen - also faktisch die Hoheit des Teams über die Planung und Schätzung des 
Backlogs nicht tolerieren. Wenn dann auch noch die Scrum-Master-Rolle nicht oder 
nur schwach besetzt ist, fehlen die entscheidenden Akteure, die für die Einhaltung 
des Lean-Prozesses einstehen. Damit bleiben entscheidende Prozessmomente zur 
Bewältigung von Krisen, wie das Daily Scrum und die Retrospektive, ungenutzt. 

Hohe Belastungen: Lean-Teams, die sich in der Krise befinden, sind auf- 
grund des permanenten Krisenmodus und der Unterminierung zentraler Lean- 
Prinzipien hohem Druck ausgesetzt, der bis zur Beeinträchtigung der Gesund- 
heit reichen kann. Sie sind der Anforderung der kurzzyklischen Lieferung von 
Produkten unterworfen, verfügen aber nicht über die Gestaltungs- und Schutz- 
möglichkeiten, die sich die Vorreiter-Teams bei der Umsetzung von Lean er- 
schlossen haben. 

Mitglieder von Lean-Teams, die im permanenten »Firefight-Modus« agieren 
und sich mit unbewältigten Altlasten konfrontiert sehen, berichten über ihre 
Arbeitsbelastung und die Folgen: 


»Die Stimmung ist so ein bisschen schlecht. Weil wir immer nur am Hetzen sind, wir 
versuchen immer das aufzuholen, was wir damals, die Miesen von damals versuchen 
wir immer noch quasi aufzuholen.« (F-58) 
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»Der Termindruck ist so hoch, ja, da kann man schon nicht mehr schlafen, das geht auf 
die Gesundheit, eindeutig.« (F-65) 


Die Beschäftigten sind sich bewusst, dass sie in diesem Modus die Probleme 
nicht systematisch bearbeiten können, sondern vielmehr »flickschustern« müs- 
sen. Dies führt objektiv in den Teufelskreis immer neuer Folgeprobleme, die 
schon absehbar sind, und subjektiv zu der Wahrnehmung, eigenen Qualitäts- 
ansprüchen in der Arbeit nicht genügen zu können und keine Wertschätzung 
zu erleben: 


»Aber letzten Endes wird man am Ende dann doch quasi nur verprügelt, also weil es 
hätte ja schon vor drei Wochen kommen müssen oder der Fehler hätte gar nicht drin 
sein müssen. Also man hat keine Chance, irgendwie es gut zu machen .« (F-58) 


Gerade das Zusammenspiel zwischen enorm hohen Belastungen und dem wahr- 
genommenen Mangel an Wertschätzung birgt die Gefahr einer Abwärtsspirale. 


3.6.6 Zusammenfassung 


Dieser Fall zeigt die Grenzen des traditionellen bürokratischen Organisations- 
modells in der Entwicklung auf. Während die Produktionsbereiche des Fall- 
unternehmens durch die Einführung von Lean große Erfolge feierten, sind 
mehrere strategische Entwicklungsprojekte auf Basis des bürokratischen »Was- 
serfallmodells« zunehmend in Schwierigkeiten geraten. Gerade dieser Vergleich 
war der strategische Ausgangspunkt für die Einführung von Lean in der Ent- 
wicklung. Das Ziel der Einführung war, auch die Entwicklung effizienter zu ge- 
stalten und die Geschwindigkeit, mit der Produkte am Markt platziert werden, 
zu erhöhen. 

Lean ist im Fallunternehmen ein strategisches Projekt des Bereichsmanage- 
ments. Es wurde Ende der 2000er Jahre im Entwicklungsbereich »top-down« 
eingeführt und sukzessive ausgerollt. Der konzeptionelle Kern von Lean ist hier 
die ganzheitliche Neuorganisation der Entwicklung. Es geht nicht nur um eine 
Sammlung von Methoden (vgl. Fall A und B), sondern um ein neues systemi- 
sches Entwicklungsmodell, bei dem die gesamte Wertschöpfungskette von der 
Entwicklung bis zur Auslieferung an den Kunden in den Blick genommen wird 
(vgl. FallC und D). Damit wird die Art, wie global verteilte Entwicklungsteams 
arbeiten, fundamental verändert. Die Release-Zyklen werden auf sechs Monate 
verkürzt, innerhalb derer die Entwicklerteams ein auslieferbares Produkt ent- 
wickeln. Die Teams selbst werden so zu einem Teil einer kurzzyklisch getakteten 
und systemisch integrierten Wertschöpfungskette. 
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Der Fall zeichnet sich dadurch aus, dass der Entwicklungsbereich bei der 
Umsetzung von Lean weit fortgeschritten ist. Zum Zeitpunkt der Untersuchung 
hatten alle Teams die Lean-Einführung absolviert, die letzten einige Monate vor 
der Untersuchung. Die breite empirische Basis ermöglichte es uns, die Entwick- 
lungsunterschiede zwischen den Teams zu untersuchen. Dabei konnten drei 
Formen identifiziert werden: 


1. Formale Lean-Teams: Diese Teams haben Lean erst vor kurzem eingeführt und 
setzen die neuen Institutionen zunächst lediglich formal um. Der Zeitraum ist 
noch zu kurz, als dass die Lean-Institutionen schon merkliche Veränderungen 
in der gelebten Praxis bewirken könnten. Entscheidend ist in dieser Phase, dass 
ein komplexer Auseinandersetzungsprozess mit dem neuen Organisationsmo- 
dell stattfindet. In unserer Untersuchung konnten drei Faktoren identifiziert 
werden, die die weitere Entwicklung der Teams beeinflussen: die Beteiligung 
des Teams bei der Einführung, der Charakter der vorherrschenden Experten- 
kultur und strukturelle Rahmenbedingungen wie Vertrauen und Sicherheit. 

2. Vorreiter-Teams: Diese Teams haben es geschafft, die Lean-Institutionen als 
Hebel für eine neue Arbeitskultur zu nutzen und eine neue Qualität der Zu- 
sammenarbeit zu etablieren. In der Untersuchung dieser Teams wird deut- 
lich, dass sich diese Entwicklung über Jahre erstreckt und ein kontinuierlicher 
Prozess ist. Charakteristisch für diese Teams ist erstens, dass sie den Status 
des formalen Teams überwunden haben und als Team zusammengewachsen 
sind. Deutlich wird dies an den Wissensdomänen der Teammitglieder, die 
sich zunehmend überlappen. Zweitens besteht der innere Kern solcher Teams 
im Empowerment. Die Teams stellen autonome Einheiten dar, verfügen über 
hohe Gestaltungsspielräume, bestimmen über ihren eigenen Workload und 
arbeiten selbstorganisiert. Drittens werden die neuen Rollen im Sinne von 
Lean »gelebt«. Sowohl der Projektleiter als auch das Produktmanagement 
(also die Product Owner) respektieren das Empowerment des Teams. Viertens 
nehmen diese Teams den kontinuierlichen Verbesserungsprozess ernst und 
treiben ihn voran - auch wenn sie bereits viel erreicht haben. 

3. Lean-Teams in der Krise: Diese Teams haben Lean eingeführt und sind den 
damit einhergehenden erhöhten Anforderungen, wie der engen Taktung 
ihrer Arbeit und den damit verbundenen kurzzyklischen Lieferverpflichtun- 
gen, ausgesetzt. Sie erleben sich in einem »permanenten Ausnahmezustand«. 
In dieser Situation werden die Lean-Institutionen, die der Entlastung dienen, 
außer Kraft gesetzt. In der Folge sind die Beschäftigten hohen Belastungen 
ausgesetzt, die bis zur Beeinträchtigung der Gesundheit reichen können. Die- 
se Teams laufen Gefahr, in eine Abwärtsspirale zu geraten. 
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Insgesamt zeigt dieser Fall exemplarisch, wo nach einem Roll-out die Schwierig- 
keiten liegen, Lean nachhaltig in der Organisation zu verankern. Gleichzeitig 
kann anhand von Teams, die Lean »zum Fliegen gebracht« haben, aufgezeigt 
werden, wie Lean funktionieren könnte und wie es zu einer neuen Arbeitskul- 
tur beitragen kann, die von den Beschäftigten positiv erlebt wird. An unserer 
Untersuchung zeigt sich, dass das Empowerment der Teams der Schlüssel und 
wichtigste Hebel dafür ist, dass eine neue Arbeitspraxis auch wirklich ge- und 
erlebt werden kann. 
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Die digitale Transformation markiert einen grundlegenden Umbruch für die 
Organisation von Kopfarbeit. Wie unsere empirischen Ergebnisse zeigen, gehen 
die Veränderungen weit über die bloße Frage der Automatisierung und des Ver- 
lusts von Arbeitsplätzen hinaus. Sie stellen vielmehr insgesamt die bisherige Or- 
ganisation von Arbeit im Büro und die Gestaltung von Innovationsprozessen in 
den Unternehmen bis hin zur Steuerung von Wertschöpfung infrage. 

Im Zuge dieses Umbruchs sind die Unternehmen gegenwärtig dabei, sich 
neu zu erfinden. Sie suchen einen Bauplan für die digitale Transformation. Als 
Leitbild kristallisiert sich hier die »agile Organisation« heraus (vgl. Boes et al. 
2016a), die einen Gegenentwurf zum fordistisch-bürokratischen Unternehmen 
und eine Antwort auf die zunehmende Komplexität und Geschwindigkeit in 
den Unternehmensprozessen bildet. 

Den Hintergrund dieser Entwicklung bildet ein Produktivkraftsprung: So ist 
mit dem Aufstieg des Internets ein digitaler Informationsraum entstanden, der die 
abstrakte Welt der Daten und Informationen mit der Lebendigkeit einer neuen 
gesellschaftlichen Handlungsebene verbindet. Als Fundament für die Arbeits- und 
Produktionsprozesse im 21. Jahrhundert kommt ihm dieselbe Bedeutung zu wie 
den Maschinensystemen im 19. und 20. Jahrhundert (vgl. Boes/Kämpf 2012). Insbe- 
sondere in den indirekten Bereichen, wo zentrale Arbeitsmittel und -gegenstände 
auf digitalen Informationen und Informationssystemen basieren, wird Arbeit in- 
formatorisch durchdrungen und neu strukturiert (vgl. Boes et al. 2016b). Komple- 
mentär dazu werden passende Organisationskonzepte in den Büros erforderlich. 

Infolgedessen finden sich gegenwärtig in vielen Unternehmen strategische 
Suchprozesse, in deren Rahmen insbesondere für die Kopfarbeit neue Organi- 
sationskonzepte zur Bewältigung der Herausforderungen der Digitalisierung 
erprobt werden. Lean erweist sich dabei in den untersuchten Bereichen der Soft- 
ware-Entwicklung, der industriellen Forschung und Entwicklung sowie der 
Verwaltung als ein strategischer Trend. In vielen Unternehmen wird derzeit ver- 
sucht, die Prinzipien von Lean bzw. der unternehmensspezifischen »Ganzheitli- 
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chen Produktionssysteme« (GPS) in die Welt der Büros zu übertragen. Sie bilden 
ein wichtiges Moment der derzeitigen Umbrüche in den indirekten Bereichen. 
Auf der einen Seite erweisen sich hier die Methoden des Shopfloor-Managements 
als wichtiges Instrument, auf der anderen Seite gewinnen gerade in den Ent- 
wicklungsbereichen agile Methoden wie Scrum schnell an Bedeutung. Dies gilt 
nicht mehr nur für die Software-Entwicklung (vgl. auch Boes et al. 2014a), son- 
dern zunehmend auch für die industrielle Forschung & Entwicklung. 

Unsere empirischen Ergebnisse zeigen, dass dieser Umbruch in der Kopf- 
arbeit insgesamt mit weitreichenden Implikationen einhergeht: 


e In Kombination mit der informatorischen Durchdringung etablieren sich mit 
Lean und agilen Methoden neue Formen der Industrialisierung von Kopfarbeit, 

e neue Formen der Transparenz halten Einzug in die indirekten Bereiche, 

e der »Expertenmodus«, als spezifische Organisationsform insbesondere hoch- 
qualifizierter Kopfarbeit, verliert an Bedeutung, 

- und nicht zuletzt kommt es im Rahmen des Umbruchs zu einer neuen Be- 
lastungskonstellation in den Büros. 


4.1 Mit Lean und agilen Methoden auf dem Weg zu neuen Formen 
der Industrialisierung von Kopfarbeit 


Die digitale Transformation hat nicht nur zu einem grundlegenden Umbruch 
in der Fertigungsarbeit geführt, sondern zu einer neuen Qualität von Industria- 
lisierung insgesamt. Es deutet sich ein »neuer Typ der Industrialisierung« (Boes 
2004) an, dessen Ausgangspunkt nicht länger die klassischen Maschinensysteme 
sind. Stattdessen wird die Informationsebene zum strategischen Zentrum einer 
Neuformierung der Wertschöpfungskette als ganzer und der digitale Fluss von 
Informationen und Daten wird zur dominanten Bezugsebene von Arbeit und 
Organisation. Auf dieser Grundlage können nicht nur die industriellen Ferti- 
gungsprozesse über das »Internet der Dinge« in neuer Qualität vernetzt werden 
(vgl. z.B. Hirsch-Kreinsen/Ittermann/Niehaus 2015). Wie unsere Untersuchun- 
gen zeigen, wird auch die Angestelltenarbeit auf Basis ihrer informatorischen 
Durchdringung und in Kombination mit komplementären Organisationsfor- 
men auf dem Shopfloor in einer neuen Weise der Industrialisierung zugänglich 
gemacht: Während mit dem digitalen Informationsraum ein Raum entsteht, in 
dem Kopfarbeit neu gedacht und strukturiert werden kann, liefern Lean-Kon- 
zepte und agile Methoden Ansatzpunkte dafür, Wertschöpfungsprozesse ent- 
lang des »flow of information« neu zu organisieren und zu integrieren. 
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Informatorische Durchdringung der Angestelltenarbeit 

In unserer Empirie können wir unterschiedliche Grade der informatorischen 
Durchdringung von Kopfarbeit differenzieren. Die Spannbreite reicht hier von 
einer Art »digitalem Fließband« in den mittelqualifizierten Verwaltungsberei- 
chen bis hin zu IT-basierten kollaborativen Entwicklungsplattformen als infor- 
matorischer Basis in den höherqualifizierten Entwicklungsabteilungen der Soft- 
ware-Programmierer und Ingenieure. 

In vielen unserer Fallunternehmen sind die mittelqualifizierten Verwal- 
tungsbereiche - von der Personalabteilung über die Finanzbereiche bis hin zu 
den unterstützenden Vertriebs-, Service- und Logistik-Abteilungen - konsequent 
digitalisiert. Der Informationsraum wird hier vollumfänglich zum »Raum der 
Produktion« (Boes 2004). Woran die Menschen konkret arbeiten, sind digitali- 
sierte Informationen, die in komplexen Informationssystemen bearbeitet und 
prozessiert werden. Ein Sachbearbeiter aus Fallunternehmen A stellt treffend 
fest: »Wir arbeiten hier nur noch mit Zahlen.« Digitale Workflows und Prozesse 
bestimmen den Arbeitsablauf, geben die einzelnen Arbeitsschritte oftmals mi- 
nutiös vor und strukturieren die Arbeitsteilung und die Zusammenarbeit mit 
Kollegen entlang der Wertschöpfungskette. Der digitalisierte Arbeitsgegenstand 
»fließt« so von Arbeitsschritt zu Arbeitsschritt wie an einem »digitalen Fließ- 
band« bis zum Kunden. Der Takt wird von modernen »Ticket-Systemen« vor- 
gegeben, die den einzelnen Beschäftigten kontinuierlich mit Aufträgen versor- 
gen. Die individuellen Handlungsspielräume werden dabei immer kleiner - die 
einzelnen Prozessschritte sind in die IT-Systeme regelrecht eingeschrieben und 
lassen ein Arbeiten am Prozess vorbei kaum noch zu. 

Aber auch in der Software-Entwicklung sowie der industriellen Forschung & 
Entwicklung ist die Zusammenarbeit in einem kollektiven Arbeitsprozess ohne 
die entsprechende informatorische Durchdringung der Entwicklungstätigkei- 
ten der höherqualifizierten Beschäftigten nicht denkbar. In komplexen IT-ba- 
sierten Kollaborationsumgebungen, wie Jira oder RTC, wird die Bearbeitung 
von Arbeitspaketen organisiert und »getrackt« (vergleichbar einem Ticket-Sys- 
tem). Nicht nur die Arbeitsteilung wird so organisiert, sondern die komplette 
Arbeit - vom Bearbeitungsstand bis hin zum programmierten Code - kann so 
für die gesamte Organisation einsehbar gemacht werden. Die einzelnen Soft- 
ware-Bestandteile können zudem über das IT-System permanent (automatisiert) 
getestet und kontinuierlich zu einem lauffähigen Produkt zusammengeführt 
werden. Der Informationsraum bildet somit auch hier das Fundament, das den 
ganzen Entwicklungsprozess integriert und synchronisiert. So können im di- 
gitalen Raum der Produktion ganze Entwicklungsabteilungen zusammenge- 
halten werden. Allerdings verlieren die Entwickler dabei auch Handlungs- und 
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Gestaltungsspielräume. Gleichzeitig dient der Informationsraum als Grundlage 
für den Wissensaustausch zwischen den Beschäftigten: z.B. mit Wikisystemen, 
in denen die Entwickler prozessbegleitend alle für den Entwicklungsprozess 
relevanten Informationen speichern, gegenseitig kommentieren und ergänzen, 
entstehen ganz neue Möglichkeiten für einen fluiden Wissenstransfer. 

Zusammengenommen zeigt sich: Für die Industrialisierung von Kopfarbeit 
bildet zunächst die Produktivkraftstruktur des Informationsraums eine Art 
»digitales Rückgrat«. In dem Maße, wie Arbeitsgegenstand und -mittel digita- 
lisierbar sind, eröffnet er eine neue Grundlage für Arbeit. Auf dieser können 
geistige Tätigkeiten entlang des »flow of information« arbeitsteilig organisiert 
und neue Formen der Kooperation und Kommunikation bis hin zum Austausch 
von Wissen in den Arbeitsprozess integriert werden. So wird es möglich, gan- 
ze Abteilungen vermittels durchgängiger Informationssysteme systemisch mit- 
einander zu vernetzen. Jenseits der »Silos« können die einzelnen Glieder der 
Wertschöpfungskette von der Entwicklung bis zum Vertrieb nahtlos aneinander 
angeschlossen werden, und der Informationsfluss bis hin zu externen Kunden 
und Lieferanten kann so gewährleistet werden. Je höher der Grad der Infor- 
matisierung ist, desto stärker kann schließlich auch die Arbeit der einzelnen 
Beschäftigten einer konsequenten, an das Flussprinzip von Lean angelehnten 
Prozessorientierung zugänglich gemacht werden. Gleichzeitig wird die Arbeit 
im digitalen Raum in bisher ungeahnter Weise transparent - und damit auch 
einer immer engermaschigen Kontrolle durch das Management zugänglich. 

Ob und in welcher Form sich allerdings die neue Produktivkraftstruktur 
des Informationsraums in entsprechende Industrialisierungskonzepte übersetzt, 
hängt nicht zuletzt von der sozialen Aushandlung in den Unternehmen bzw. 
von der konkreten Ausgestaltung neuer Formen der Arbeitsorganisation in den 
Büros ab: Denn die Durchsetzung des neuen Typs der Industrialisierung und 
seine Erscheinungsformen im Büro sind keine rein »technischen« Angelegenhei- 
ten. Sie sind vielmehr eine Frage der konkreten sozialen Praxis in den Unterneh- 
men (und als solche mithin stark »umkämpft«). Im Moment lassen sich hierbei 
auf Basis unserer Empirie wiederum unterschiedliche Ansätze und Umsetzungs- 
formen in den mittel- bis hochqualifizierten Bereichen differenzieren. 


Standardisierung und Prozessorientierung im Büro 

In den mittelqualifizierten Verwaltungsabteilungen verbindet sich das oben 
beschriebene »digitale Fließband« mit verschiedenen Methoden aus dem Lean- 
Baukasten, die aus den »Ganzheitlichen Produktionssystemen« in die Büros 
übertragen werden: Während das Shopfloor-Management dazu dient, die Trans- 
parenz und den Wissenstransfer in der konkreten Praxis im Arbeitsprozess zu 
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verbessern, sorgen Standardisierung und Prozessoptimierung für einen tief- 
greifenden Umbruch in den administrativen Kernarbeitsprozessen. Vor dem 
Hintergrund der oftmals geringeren »Primärmachtpotentiale« und der weniger 
ausgeprägten individuellen Expertenkultur können die Lean-Methoden hier viel 
weiterreichend umgesetzt werden als z. B. in der industriellen Forschung & Ent- 
wicklung. So wird das Shopfloor-Board konsequent genutzt, um die individuellen 
Arbeitsplanungen aufeinander abzustimmen und den entsprechenden Arbeits- 
fortschritt kontinuierlich auszuwerten. Unsere Empirie veranschaulicht, wie 
hier die individuellen Arbeitsplanungen der Beschäftigten transparent gemacht, 
der Zeitaufwand in Stunden geschätzt und der Arbeitsfortschritt anhand von 
Kennzahlen an den Boards engmaschig abgebildet werden kann. 

Gleichzeitig können die Lean-Methoden dazu genutzt werden, die Kollektivie- 
rung des Wissens und die Kooperation der Beschäftigten voranzutreiben. Dazu 
dienen die täglichen Meetings am Shopfloor-Board, die einen Raum für Wissens- 
austausch und die gegenseitige fachliche Unterstützung zwischen den Beschäf- 
tigten erzeugen. Aber auch durch Standardisierungsmaßnahmen, wie z.B. von 
den Beschäftigten selbst entwickelte »Standardarbeitsblätter« oder mittels Beob- 
achtung von außen erstellte »Tätigkeitsanalysen«, wird versucht, das individuelle 
Wissen der Beschäftigten systematisch der Organisation zugänglich zu machen. 

Eine besondere Form der Standardisierung und Prozessorientierung in 
den Fallunternehmen findet sich im Rahmen der Shared-Service-Konzepte (vgl. 
z.B. Bergeron 2003). Hier werden so genannte »transaktionale« Tätigkeiten mit 
einem hohen repetitiven und geringen kreativen Anteil reorganisiert. Betrof- 
fen sind meist interne Dienstleistungsfunktionen wie Accounting, Controlling, 
HR- oder IT-Services, die bislang an verschiedenen Standorten verteilt waren. 
Um diese an einem Standort zusammenführen (und dann meist auch in Nied- 
riglohnländer verlagern) zu können, werden die entsprechenden Arbeitsabläu- 
fe zunächst detailliert dokumentiert und ausgewertet und dann als Prozesse 
in vereinheitlichte IT-Systeme überführt, die den Beschäftigten nun in Form 
eines rigiden und stark standardisierten Workflow gegenübertreten. Je genauer 
dokumentiert die Prozesse sind, desto eher können sie im digitalen Zeitalter 
vollständig automatisiert werden. Gleichzeitig wird mit der zunehmenden Digi- 
talisierung Arbeit in bisher nicht gekanntem Ausmaß transparent und messbar. 
Alles, was im Informationsraum getan wird, hinterlässt eine Vielzahl von Daten 
(z.B. Mauszeigerbewegungen in Call-Centern oder die Bearbeitungszeiten von 
»Tickets« im IT-Support). Diese können nun aufgezeichnet, ausgewertet, vergli- 
chen und konsequent für eine Optimierung der Prozesse verwendet werden. 

Zusammengenommen setzen das Shopfloor--Management und die verschiede- 
nen Formen der Standardisierung und Prozessoptimierung bis hin zum Einsatz 
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von Shared-Service-Konzepten allesamt unmittelbar an der informatorischen 
Durchdringung der Tätigkeiten in den Verwaltungsbereichen an, um diese ver- 
mittels neuer Organisationsmethoden zu rationalisieren. Je transparenter die 
Arbeit, desto besser können die Prozesse auch auf dem Shopfloor entlang des 
»flow of information« strukturiert werden. So wird es - ganz im originär Tay- 
lor’schen Sinne - möglich, administrative Angestelltentätigkeiten einer genauen 
Beobachtung, Messung und datenbasierten Auswertung zu unterziehen, um sie 
anschließend »wissenschaftlich« zu veredeln. Darauf aufbauend können Prozes- 
se optimiert und verschiedene Tätigkeiten in einem standardisierten »one best 
way« verallgemeinert werden. 


Neues industrialisiertes Entwicklungsmodell 

In den höherqualifizierten Bereichen der Software-Entwicklung und industriel- 
len Forschung und Entwicklung wird hingegen oft das Prinzip der »Agilität« 
zum zentralen Ansatzpunkt einer Industrialisierung kreativer Kopfarbeit. Der 
Hintergrund besteht hierbei darin, dass der Wandel der Innovationsprozesse 
und die zunehmende Komplexität der Produktentwicklung im Zuge der Digita- 
lisierung die Organisation der Wissensarbeit an die Grenzen des bürokratischen 
Modells geführt haben. 

Mit den neuen Anforderungen an eine »agile Organisation« (vgl. Boes et al. 
2016a) — Verbesserung der Kundenorientierung, Steigerung der Innovationsge- 
schwindigkeit und Veränderungsflexibilität sowie Erhöhung der Transparenz 
hinsichtlich der Wissensressourcen - verändert sich auch die Arbeitssituation 
der Beschäftigten hier grundlegend. Im Rahmen der Einführung agiler Me- 
thoden oder der Übertragung insbesondere des Shopfloor-Managements aus den 
»Ganzheitlichen Produktionssystemen« kommt vor allem den »Stehungen« oder 
Daily Scrums an den Scrum- bzw. Shopfloor-Boards eine entscheidende Bedeutung 
zu. Unsere empirischen Ergebnisse zeigen, dass, ähnlich wie in der Verwaltung, 
die Meetings an den Boards auch hier dazu dienen, die Arbeitsplanung und 
den Arbeitsstand im Team zu visualisieren. Allerdings sind die Aufgabenbe- 
schreibungen und Aufwandsschätzungen, die auf den »Kärtchen« abgebildet 
sind, oftmals weniger konkret, lassen also mehr Interpretationsspielraum und 
beziehen sich auch seltener auf eine detaillierte individuelle Arbeitsplanung als 
auf die Abbildung des Arbeitsflusses des Gesamtteams. Dementsprechend liegt 
der Fokus bei den entsprechenden Treffen weniger auf der Kalibrierung und 
Priorisierung von Aufgaben als vielmehr auf dem fachlichen Austausch und der 
gegenseitigen Unterstützung. 

Während es sich bei den Experimenten mit agilen Methoden (in Fallunter- 
nehmen E) oder dem Shopfloor-Management (Fallunternehmen A und B) bisher 
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lediglich um erste, zaghafte Versuche der Unternehmen handelt, die »Wissens- 
silos« ihrer hochqualifizierten Beschäftigten ein Stück weit zu öffnen, sind an- 
dere Vorreiterunternehmen schon einen Schritt weiter. Dort ist auf der Basis der 
Kombination von agilen Methoden mit den Prinzipien der Lean Production ein 
neues Paradigma für die Organisation kreativer Kopfarbeit entstanden (vgl. Boes 
et al. 2014a), das sich als industrialisiertes Entwicklungsmodell in der Software- 
Entwicklung flächendeckend durchsetzt (vgl. exemplarisch unsere Fallstudien C 
und D) und heute auch in der klassischen Ingenieursarbeit immer häufiger zum 
Einsatz kommt (Fallstudie F). 

Im Gegensatz zum alten »Wasserfallmodell« wird hier nicht mehr in lang- 
wierigen Entwicklungszyklen von bis zu 24 Monaten gedacht, sondern in kurz- 
zyklischen Takten (Sprints) von zwei bis vier Wochen iterativ Usable Software ent- 
wickelt. Insgesamt wird es so möglich, z.B. jedes halbe Jahr ein neues Release an 
den Kunden auszuliefern. Im Rahmen des neuen Entwicklungsmodells wird die 
zu entwickelnde Software konsequent in einzelne Arbeitspakete und Aufgaben 
zerlegt, die im Backlog entweder von Produktmanagement und Führungskräften 
oder aber von den Entwicklungsteams selbst organisiert werden. Die Entwickler 
ziehen sich ihre Aufgaben nach und nach aus dem Backlog, und die Entwick- 
lung selbst erfolgt »test-driven«, d.h. die entwickelten Codebestandteile werden 
nicht erst nach ihrer Fertigstellung und am Ende des Entwicklungsprozesses 
auf ihre Qualität getestet, sondern permanent. Die Entwickler bearbeiten in der 
Entwicklungsumgebung ihre Teilprodukte und können diese mitunter täglich 
in das Gesamtprodukt integrieren und testen lassen. Dadurch kann schon in 
einem sehr frühen Entwicklungsstadium das Zusammenspiel der Teilprodukte 
getestet werden. Die Integrations- und Testprozesse werden meist automatisiert 
über Nacht durchgeführt, sodass die Entwickler bereits am Morgen die entspre- 
chenden Ergebnisse bekommen, deren Bearbeitung dann oberste Priorität hat. 

Unsere empirischen Fallbeispiele zeigen, wie ganze Entwicklungsabteilun- 
gen mit mehreren Tausend Entwicklern so nach einem objektiven Prozess in 
synchron getakteten Wertschöpfungsketten organisiert werden können. Für die 
Beschäftigten führt die synchrone Taktung der Entwicklungsorganisation oft 
dazu, dass zeitliche Puffer in der Arbeit verloren gehen und der Druck in der 
Arbeit steigt, weil die Interdependenzen zwischen den einzelnen Entwickler- 
teams zunehmen. Ähnlich einer Just-in-time-Produktion können ausbleibende 
Lieferungen oder ungeklärte Schnittstellen auch in der Entwicklung viel unmit- 
telbarer und schneller zur Eskalation führen, sodass ein hoher Abstimmungsbe- 
darf entsteht. Denn schließlich können Modifikationen einzelner Teams - z.B. 
in Bezug auf die Architektur oder den Code - andere Teams unter großen Druck 
setzen. 
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Begleitet wird die Arbeit im neuen Entwicklungsmodell mit mittlerweile 
oftmals digitalisierten Scrum-Boards in den Büros der Entwickler, wo die Aufga- 
ben und der Arbeitsfortschritt der einzelnen Entwickler visualisiert werden. Die 
teilweise täglichen Meetings (Daily Scrums) dienen nicht nur der Herstellung 
von Transparenz über Arbeitsplanung und Bearbeitungsstand, sondern werden 
vor allem zur Kollektivierung des Wissens der einzelnen Entwickler genutzt, 
indem jeder Einzelne über seine gegenwärtige Arbeit und auch die dabei an- 
fallenden Schwierigkeiten und Probleme berichtet. So kann das Know-how der 
Kollegen »angezapft« und ggf. konkrete Unterstützung organisiert werden. Vor- 
aussetzung dafür ist allerdings auch ein entsprechender »Vorrat« an sich überlap- 
penden Kompetenzprofilen in den Teams. Gleichzeitig dienen diese Meetings 
dazu, die Arbeit verbal zu kontextualisieren: Hier werden die Aufgaben, die in 
den IT-Systemen hinterlegt sind, mit Inhalt gefüllt und das notwendige Kon- 
textwissen ausgetauscht. So ist auf der IT-basierten Entwicklungsplattform z.B. 
lediglich erkennbar, dass eine Aufgabe bereits sehr lange bearbeitet wird, aber 
nicht, warum oder welche Schwierigkeiten damit verbunden sind. Durch die 
Daily Scrums wird eine zusätzliche und komplementäre Ebene der Transparenz 
geschaffen, die in den IT-Systemen fehlt. Insbesondere für Führungskräfte (oder 
ggf. für die Selbststeuerung des Teams) kann so ein inhaltlicher Kontext geschaf- 
fen werden, der es ermöglicht, steuernd einzugreifen. Die individuelle Entwick- 
lerarbeit verliert damit mehr und mehr ihren Charakter einer »Black Box«. 

Die Spielarten des skizzierten neuen Entwicklungsmodells reichen in der 
Praxis von solchen, die sehr stark auf Selbstorganisation und Empowerment der 
Teams setzen, bis hin zu Formen, die genau auf dieses Empowerment verzichten 
und in denen die Teams dann nur noch ihre zerstückelten Arbeitspakete wie 
an einem Fließband »abarbeiten«. Welche Variante des neuen industrialisierten 
Entwicklungsmodells schließlich zum Tragen kommt, hängt entscheidend von 
der sozialen Praxis in den Unternehmen ab - und davon, welche Bedeutung dem 
Thema Empowerment von den verschiedenen Akteuren jeweils beigemesen wird. 


Industrialisierung und Digitalisierung 

Insgesamt zeigt sich sowohl in den mittel- als auch in den höherqualifizierten 
Bereichen, wie die Kombination eines digitalen »Raums der Produktion« mit 
Lean und agilen Methoden auf dem Shopfloor die Kopfarbeit neuen Formen 
der Industrialisierung zugänglich macht. Den Unternehmen eröffnen sich so 
neue Möglichkeiten, selbst hochqualifizierte Wissensarbeit systematisch und ra- 
tional zu organisieren, um sie — mittels Transparenz und Kontrolle sowie einer 
Kollektivierung von Wissen - plan- und wiederholbar zu machen. Ähnlich wie 
bei der Industrialisierung der Handarbeit im 19. Jahrhundert zeigt sich, wie nun 
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auch geistige Tätigkeiten unabhängig vom individuellen Geschick des Einzelnen 
organisiert werden können. Entscheidend ist hier, dass im digitalen »Raum der 
Produktion« auf ähnliche Weise ein »objektiver Prozess« organisiert wird, wie es 
in der »großen Industrie« durch die Maschinensysteme oder im Fordismus mit 
dem Fließband geschehen ist. 

Die konkreten Strategien zur Industrialisierung der Kopfarbeit unterschei- 
den sich dabei je nach den Bereichen, was nicht zuletzt auch mit unterschied- 
lichen Primärmachtpotenzialen zusammenhängt. Während sich in der Ver- 
waltung stärker das Bild eines »digitalen Fließbands« gepaart mit einer neuen 
Transparenz in den Büros abzeichnet, dominieren in den höherqualifizierten 
Bereichen der Software-Entwicklung sowie der industriellen Forschung & Ent- 
wicklung kollektive Formen der Arbeitsorganisation auf der Basis von Lean und 
agilen Methoden, die darauf zielen, die individuellen »Expertensilos« aufzubre- 
chen. Gemeinsam ist beiden Strategien, dass sie auf der neuen Dominanz der 
Informationsebene im Zuge des neuen Typs der Industrialisierung basieren, die 
einerseits die Digitalisierung und Standardisierung der transaktionalen Tätigkei- 
ten (bis hin zu ihrer Automatisierung) ermöglicht und andererseits in Form des 
Informationsflusses im digitalen »Raum der Produktion« das Rückgrat der neuen 
Organisationskonzepte in den kreativen Bereichen der Wissensarbeit darstellt. 

In der Praxis ist also die Bedeutung der Digitalisierung bzw. Informatisie- 
rung als Grundlage für neue Formen der Arbeitsorganisation zur Industriali- 
sierung von Kopfarbeit sehr gut erkennbar. Umso mehr erstaunt es, dass dieser 
Zusammenhang den Akteuren selbst oftmals nicht bewusst ist. So stellt die Di- 
gitalisierung in den konzeptionellen Überlegungen vieler betrieblicher Lean- 
Ansätze eine Blindstelle dar und spielt nach der Einschätzung der befragten 
Experten »keine wesentliche Rolle«. Das ist deswegen so erstaunlich, weil Lean 
in der Fertigung schon immer ganz wesentlich auf einem (erst analogen, später 
digitalen) Informationssystem basierte: dem Kanban-Informationssystem (vgl. 
Ohno 1993). Es bildet die Grundlage für die Einführung des Flussprinzips von 
Lean, das z.B. gewährleistet, dass an jeder Station im Prozess der Fertigung und 
Montage zum richtigen Zeitpunkt auch die richtigen Teile vorliegen. 

Die Einführung des Flussprinzips auf der Grundlage von Informationssys- 
temen bildete so schon hier den entscheidenden Hebel, um die manuelle Fer- 
tigungsarbeit in der Praxis nach einem objektiven Prozess zu organisieren (vgl. 
z.B. auch unseren Fall A). Dies bestätigt sich nun auch in der zunehmenden 
Prozessorientierung durch das »digitale Fließband« in den mittelqualifizierten 
Feldern der indirekten Bereiche. Hier sind es die fortschreitende Informatisie- 
rung der Arbeit und ihre konsequente Überführung in durchgängige IT-Pro- 
zesse, die einen Informationsfluss ermöglichen, der diese Bereiche dem Fluss- 
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prinzip und entsprechenden Lean-Methoden öffnet. Ähnlich verhält es sich mit 
den IT-Systemen, mittels derer - wie in den Fallunternehmen C, D und F - nicht 
nur die Arbeit ganzer Entwicklungsabteilungen durchgängig über den »flow of 
information« organisiert, sondern auch der Arbeitsgegenstand in einen perma- 
nenten Fluss integriert und (automatisiert) getestet wird. Wo diese IT-basierten 
Informationssysteme nicht bestehen, wie z.B. in Fallunternehmen B, entstehen 
Brüche im Arbeitsprozess, die dann sehr aufwändig personell überbrückt wer- 
den müssen. 


4.2 Neue Transparenz und Öffentlichkeit in der Arbeit 


In den Ausführungen zu den neuen Formen der Industrialisierung von Kopf- 
arbeit ist bereits angeklungen, dass der Umbruch von Arbeit in den indirekten 
Bereichen ganz wesentlich mit einer neuen Transparenz einhergeht: Die Arbeit 
in den Büros findet immer weniger im »stillen Kämmerlein« statt und wird zu- 
nehmend sichtbar und »öffentlich«. Die neuen Formen von Transparenz und 
Öffentlichkeit (vgl. Bultemeier/Boes 2013) basieren nicht allein auf der informa- 
torischen Durchdringung der Büros und den entsprechenden IT-Systemen, wie 
z.B. Jira oder RTC. Wie unsere empirischen Untersuchungen zeigen, hat gerade 
auch die Einführung von Lean und agilen Methoden dazu beigetragen, dass 
neben digitalen auch neue diskursive Formen von Transparenz in den Teams 
entstehen - und zwar sowohl in den höherqualifizierten Bereichen der indus- 
triellen Forschung & Entwicklung und der Software-Entwicklung als auch in 
der Verwaltung. Dazu dienen insbesondere die »Stehungen«, Daily Scrums oder 
»Stand-ups«, die eine neue Kultur der Kommunikation und des Austauschs 
befördern, aber auch die Visualisierung und systematische Offenlegung von 
Arbeitsständen, Aufwendungen und Zuständigkeiten sowie der zunehmende 
Einsatz von Kennzahlensystemen als Steuerungsinstrument für die Unterneh- 
mensführung. 


Neue Meeting-Routinen 

Als wesentlich für einen einschneidenden Umbruch im Büro erweisen sich in 
unserer Empirie zunächst jene Formen der Öffentlichkeit und Transparenz, die 
mit den neuen Meeting-Routinen von Scrum oder des Shopfloor-Managements 
einhergehen. Hier legen die Beschäftigten in regelmäßigen, oft täglichen Ab- 
ständen ihren Arbeitsfortschritt sowie die individuellen Planungen offen. Ent- 
scheidend ist hier der teamöffentliche Diskurs, in dem die einzelnen Arbeitsauf- 
gaben u.a. auch mit Blick auf ihre Bearbeitungsdauer ausgewertet werden. So 


182 


Zusammenführung der Ergebnisse 


kann sichtbar gemacht werden, woran jeder Mitarbeiter jeden Tag arbeitet, welche 
Probleme er aktuell mit seiner Aufgabe hat und wieviel Zeit er darauf verwendet. 

Viele Angestelltentätigkeiten, die früher von außen kaum einsehbar und 
steuerbar waren, werden so nun transparent. Früher, in der klassischen Projekt- 
arbeit, bekamen z.B. Software-Entwickler ihre Aufgaben individuell vom Pro- 
jektleiter zugewiesen, und für die Kollegen war es nicht transparent, wer was 
macht und wieviel Zeit jeweils für welche Aufgaben aufgewendet wird. Durch 
den regelmäßigen Austausch am Board hat sich dies nun geändert. 


Das Team als Ressource und als Kontrollinstanz 

Diese »absolute Transparenz« (so ein Entwickler in Fallunternehmen C) im Zuge 
der Meeting-Routinen geht mit entscheidenden Veränderungen in der Arbeits- 
weise der Teams und ihrer Sozialintegration einher. Dies hat in der Praxis zwei 
Seiten: Zum einen wird die Teamebene gestärkt, indem die regelmäßigen Mee- 
tings einen Raum für den Austausch von Erfahrungen und Wissen, aber auch 
für die gegenseitige Unterstützung konstituieren. Dies birgt nicht zuletzt neue 
Chancen für die Selbstorganisation und -steuerung im Team, z. B. wenn die täg- 
lichen Treffen genutzt werden, um individuelle Belastungsspitzen abzufedern. 
Das Team kann so als wichtige Ressource für jeden Einzelnen erkannt und 
genutzt werden - sei es im Rahmen einer Kultur der engen inhaltlichen Ko- 
operation oder im Zuge wechselseitiger Unterstützung und eines solidarischen 
Umgangs mit Arbeitsdruck und steigenden Arbeitsanforderungen. Mit der Zu- 
nahme der Interaktion und Zusammenarbeit sowie der Zentrierung auf das 
Team steigen allerdings auch die Anforderungen an das Konfliktmanagement. 
Wenn das Team als ganzes bestimmt, wie etwas gemacht wird und wie nicht, 
dann »prallen halt auch sehr harte Meinungen aufeinanders, berichtet etwa ein 
Befragter aus Fallunternehmen C. 

Konfliktpotenzial resultiert dabei nicht zuletzt auch daraus, dass mit der 
neuen Transparenz im Team auch der individuelle Leistungsbeitrag des Einzel- 
nen stärker sichtbar wird — sowohl für das Management als auch für die Kol- 
legen im Team. Damit treten auch Leistungsunterschiede offener zutage, die 
eine Herausforderung für die Teamintegration darstellen. Dies verbindet sich 
mit der anderen Seite der wachsenden Transparenz: Die neue Öffentlichkeit im 
Team kann nämlich auch als Kontrollinstrument interpretiert und von den Be- 
schäftigten als Bedrohung und Belastung empfunden werden. Das gilt sowohl 
für eine gewisse »peer group pressure« im Team (vgl. auch Vormbusch 1999) 
als auch für eine »Überwachung« durch das Management. In unserer Empirie 
ist z.B. oft von Rechtfertigungsdruck oder einem »Offenbarungseid« die Rede. 
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Neue Möglichkeiten der Kontrolle und Steuerung für das Management 
Für das Management bestehen im Rahmen von Scrum oder des Shopfloor-Ma- 
nagements ganz unmittelbar neue Kontrollmöglichkeiten schon allein dadurch, 
dass auf den Boards Aufgabenpakete in ihrem Arbeitsfortschritt visualisiert und 
mit Verantwortlichkeiten hinterlegt sind. So werden Aufgaben und Arbeitsab- 
läufe nach außen permanent sichtbar und auch für das Management einsehbar. 
Von den Beschäftigten wird dies oft als »komische Kontrolle« und »eine Art 
Überwachung« erlebt. Insbesondere in den hochqualifizierten Bereichen erzeu- 
gen diese neuen Kontrollpotenziale Misstrauen und Kritik. Der Eindruck, vom 
Management kontrolliert zu werden, verschärft sich natürlich, wenn Führungs- 
kräfte auch noch regelmäßig selbst an den Stehungen teilnehmen, was im Rah- 
men des Shopfloor-Managements durchaus üblich ist. 

Insbesondere in der Software-Entwicklung und industriellen Forschung & 
Entwicklung, die für das Management lange Zeit eine »Black Box« dargestellt 
haben, werden im Rahmen von Lean und agilen Methoden nun Inhalte, Abläufe 
und Arbeitsfortschritte erheblich transparenter. Grundlage hierfür ist, dass grö- 
ßere Entwicklungsaufgaben in kleinere Arbeitspakete zerlegt und Arbeitsstand, 
Aufwände sowie Zuständigkeiten visualisiert werden, sodass schließlich auch 
die individuelle Auslastung der einzelnen Mitarbeiter kontinuierlich sichtbar 
wird. Auch die Burndown-Charts, auf denen regelmäßig der Arbeitsfortschritt 
dokumentiert wird, werden von den Beschäftigten als ein Kontrollinstrument 
erfahren und oft als »Gängelung« empfunden. 

Für das Management stellen diese Formen der informatorischen Durch- 
dringung der Arbeitsprozesse eine zentrale Grundlage für die Steuerung und 
Kontrolle der Arbeitsabläufe und eine Öffnung der Angestelltenbereiche in 
Richtung einer »systemischen Integration« dar. Erst durch die entsprechende 
Transparenz erhält das Management die Möglichkeit, den Arbeitsstand perma- 
nent zu evaluieren und ins Verhältnis zur Gesamtorganisation zu setzen. Dazu 
dienen nicht zuletzt auch eigene Meeting-Routinen auf der Führungsebene, 
z.B. im Rahmen von Scrum of Scrums, oder das Kaskadieren von Stand-ups der 
Entwicklerteams auf die Projektleiter- und Produktmanagement-Ebene, um 
den informatorisch abgebildeten Arbeitsstand kommunikativ zu kontextuali- 
sieren. Erst so können auch komplexe Projekte in der Software-Entwicklung 
oder industriellen Forschung & Entwicklung gesteuert werden, indem in be- 
gleitenden diskursiven Prozessen Probleme rechtzeitig eskaliert sowie Themen 
und Kapazitäten entsprechend umpriorisiert werden können - und zwar im 
Rahmen abgestimmter Entscheidungsprozesse und mit Rücksicht auf die Ge- 
samtorganisation. 
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Bedeutungszunahme von Kennzahlen 

Gerade in den Angestelltenbereichen klassischer Industrieunternehmen, die ver- 
suchen, ihre Erfahrungen mit Lean bzw. »Ganzheitlichen Produktionssystemen« 
unmittelbar von den direkten auf die indirekten Bereiche zu übertragen, haben 
auch Kennzahlensysteme auf der Grundlage informatorischer Durchdringung 
an Bedeutung gewonnen. Das gilt - im Rahmen des Shopfloor-Managements — 
sowohl für die Verwaltungs- als auch für die Entwicklungsbereiche. Sie werden 
hier, wie z.B. in unseren Fallunternehmen A und B, zum Bestandteil einer täg- 
lichen Routine im Büro und dienen meist in erster Linie dazu, die »Produktivi- 
tät« in den indirekten Bereichen transparent zu machen. Dies veranschaulichen 
die Beispiele aus unserer Empirie: Oft werden z.B. die Anzahl der Stunden 
gemessen, die wirklich einen Kundennutzen erzeugen, oder der tägliche Um- 
satz, die Anzahl der abgearbeiteten Aufträge und die telefonische Erreichbar- 
keit im Vertrieb. In Entwicklungsabteilungen ist es beispielsweise der Anteil 
der Arbeitszeit, der auf genuine Entwicklungsprojekte verwendet wurde, der 
in Kennzahlen festgehalten wird. Andere Kennzahlen, wie etwa die Summe 
»in time« erledigter Meilensteine, machen die aktuelle Leistungsfähigkeit und 
Planungstreue der Teams sichtbar, oder sie dienen dazu, die generelle Arbeits- 
last zu messen, etwa durch die Anzahl der zu bearbeitenden Aufträge oder un- 
geplanten Aufgaben. 

Interessant ist, dass die Aktualisierung der Kennzahlen oft der Ausgangs- 
punkt in den Stehungen am Shopfloor-Board ist. Sie werden hier von den Teams 
meist täglich überprüft und besprochen. Durch diskursive Prozesse gelingt es, 
die Kennzahlen zu einem zentralen und lebendigen Moment in der Arbeits- 
praxis der Teams zu machen. Als zentraler Gegenstand des Austauschs am 
Shopfloor-Board werden die Kennzahlen in der sozialen Welt der Teams bedeu- 
tungsvoll und zu einer relevanten Bezugsgröße: Der Diskurs motiviert die Team- 
mitglieder, auf ein gemeinsames Ziel hinzuwirken, und befördert - im Rahmen 
einer gewissen Wettbewerbsorientierung - eine Art »Wir-Gefühl«. So kann über 
die Ebene der »Öffentlichkeit« die soziale Anerkennung der Kennzahlen als ge- 
meinsam getragene Steuerungsgröße gestärkt werden. 

Dies gelingt vor allem dort, wo die Teams ihre Kennzahlen selber entwi- 
ckeln und somit subjektive Relevanzen setzen können. Vom Management vor- 
gegebene Kennzahlen, deren Sinn von den Beschäftigten nicht unmittelbar ge- 
teilt wird, rufen hingegen oft Skepsis und Kritik hervor. Sie gelten häufig als 
»zu oberflächlich« und erscheinen lediglich als Versuch des Managements, »nur 
irgendwie Transparenz« zu schaffen. Dagegen reflektiert eine Befragte aus Fall- 
unternehmen A: »Der eigentliche Wert der Kennzahlen ist ihre Entstehung, weil 
man dann in der Diskussion über die richtigen Themen ist.« 
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In diesem Sinne können Kennzahlen - durch ihre ständige Diskussion und 
ggf. Anpassung - zu einer orientierenden und steuernden Instanz auch im Pro- 
zess der Selbstorganisation der Teams werden. Gleichzeitig vermitteln sie - im 
Sinne der systemischen Integration des gesamten Unternehmens - zwischen der 
Selbstorganisation in den Teams und der Ebene des (hierarchischen) Manage- 
ments. Dies kann z.B. wie in unserem Fallunternehmen A dadurch geschehen, 
dass die Stehungen am Shopfloor-Board systematisch kaskadiert werden - und 
zwar täglich. Jeden Tag treffen sich nach den Stehungen im Team hier die Team- 
leiter zu ihrer eigenen Stehung, danach die Abteilungsleiter usw., bis hin zur 
Werksleitung. In diesem Fall können die aktualisierten Kennzahlen jeden Tag 
auf allen Führungsebenen transparent gemacht und Probleme früh erkannt und 
eskaliert werden. Für das Management entsteht hier die Möglichkeit, täglich 
den Arbeitsfortschritt zu kontrollieren und steuernd einzugreifen. 


Systemische Integration der Angestelltenbereiche 

Zusammenfassend stellen die neuen Formen der Arbeitsorganisation im Rah- 
men von Lean und agilen Methoden einen wichtigen Ansatzpunkt für die Öff- 
nung der Angestelltenbereiche in Richtung einer systemischen Integration dar, 
wie sie im Leitbild der »agilen Organisation« angelegt ist (vgl. Boes et al. 2016a): 
Wie unsere empirischen Ergebnisse zeigen, stärkt die neue Qualität der Trans- 
parenz und Öffentlichkeit innerhalb der Teams einerseits den kommunikativen 
Austausch und die Selbststeuerung. Andererseits geht damit aber auch eine 
Transparenz nach außen bzw. oben einher, die dem Management einen besseren 
Einblick in die Angestelltentätigkeiten (teilweise bis hin zur Ebene des individu- 
ellen Arbeitsplatzes) gewährt und somit eine entscheidende Voraussetzung für 
ihre bessere Kontrolle und Steuerung im Sinne der Gesamtorganisation dar- 
stellt. Auf dieser Grundlage können schließlich die Koordinationsmechanismen 
des »Steuerns nach Zahlen« und der »Öffentlichkeit« (Bultemeier/Boes 2013) ef- 
fektiv miteinander verbunden werden: Während unterschiedliche Formen der 
informatorischen Durchdringung des Arbeitsprozesses - von den Informatio- 
nen auf den Shopfloor-Boards und in den durchgängigen IT-Systemen bis hin 
zu Burndown-Charts und Kennzahlen - die entscheidenden Zahlen, Daten und 
Fakten liefern, werden diese in einer Kaskade von Meetings und in kommunika- 
tiven Austausch- und Verhandlungsprozessen gemäß ihrer wirklichen Komple- 
xität kontextualisiert und interpretiert (vgl. Boes/Kämpf/Lühr 2016d). 

Für die Beschäftigten hat die neue Transparenz und Öffentlichkeit in der 
Arbeit allerdings noch eine andere Seite. Sie bildet zwar die entscheidende Vo- 
raussetzung dafür, das Team als zentrale Ressource des Einzelnen erfahrbar zu 
machen sowie im Rahmen von Prozessen der Selbstorganisation und kollekti- 
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ven Lernschleifen das Empowerment zu stärken. Gleichzeitig entstehen dadurch 
aber auch neue Möglichkeiten und Potenziale zur Kontrolle - Kontrolle sowohl 
durch das Management als auch durch das Team selbst im Rahmen der Aus- 
übung von »peer group pressure«. Das liegt nicht zuletzt daran, dass durch den 
Einzug von Transparenz und Öffentlichkeit der »Expertenmodus« (Boes et al. 
2014a; Boes/Kämpf/Lühr 2016c) in Frage gestellt wird, der für die bisherige 
Arbeitsorganisation gerade der hochqualifizierten Angestellten bislang konsti- 
tutiv war. 


4.3 Abschied vom Expertenmodus — Zwischen Austauschbarkeit 
und einer neuen Qualität der Nutzung geistiger Produktivkraft 


Im Gegensatz zu ihren Kollegen in den einfach- bis mittelqualifizierten Berei- 
chen ist die Konfrontation mit den neuen Formen der Industrialisierung von 
Kopfarbeit - mit Standardisierung, Prozessorientierung und Transparenz - für 
die hochqualifizierten Angestellten eine vergleichsweise neue Erfahrung. Die 
spezifische Organisationsform ihrer Arbeit, die wir als »Expertenmodus« (Boes 
et al. 2014; Boes/Kämpf/Lühr 2016d) bezeichnen, unterscheidet sich aufgrund 
der gegebenen Autonomiespielräume und Freiheitsgrade grundsätzlich von der- 
jenigen der »normalen« Angestellten. 

Unsere empirischen Fallbeispiele zeigen, dass dieser Expertenmodus im Zuge 
des Umbruchs in der Kopfarbeit gegenwärtig in eine Krise gerät, der verschie- 
dene Ursachen zugrunde liegen. Zum einen spielt hier schlicht das Wachstum 
der indirekten Bereiche in den klassischen Industrieunternehmen eine Rolle. 
Auch vor dem Hintergrund ausgeschöpfter Rationalisierungspotenziale in den 
direkten Produktionsbereichen geraten diese Bereiche daher zunehmend in den 
Fokus von Reorganisationsmaßnahmen (vgl. exemplarisch unsere Fallstudien A 
und B). Zum anderen haben Globalisierung und Digitalisierung die Marktbe- 
dingungen stark verändert und eine »Zeitenwende« für hochqualifizierte Be- 
schäftigte eingeleitet (Boes/Kämpf 2010; vgl. auch Boes/Trinks 2006). Zuneh- 
mender Kostendruck, wachsende Komplexität und die hohe Geschwindigkeit, 
mit der sich Technologien und Innovationsprozesse verändern, haben sowohl in 
der Software-Industrie (vgl. Fallstudien C und D) als auch in den Forschungs- und 
Entwicklungsabteilungen großer Industrieunternehmen (Fallstudien E und F) 
dazu geführt, den Expertenmodus grundlegend in Frage zu stellen. 

Dabei deutet sich an, dass sich die neuen Formen der Industrialisierung 
von Kopfarbeit im Rahmen der Einführung von Lean und agilen Methoden 
als Wegbereiter für einen Abschied vom traditionellen Expertenmodus erweisen 
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könnten. Unsere Fallstudien zeigen, dass sich im Zuge der Digitalisierung in den 
Unternehmen jenseits des funktionalen »Spezialisten« und unternehmerisch 
orientierten »Generalisten« (vgl. Faust/Jauch/Notz 2000; Walgenbach/Kieser 
1995) ein neues Verständnis von Expertentum herauskristallisiert: Adressiert 
wird nun der Kollektivexperte. Transparenz und Öffentlichkeit auf der einen 
sowie Standardisierung und Prozessorientierung auf der anderen Seite zielen 
darauf, den einzelnen Experten aus seinem »Silo« herauszulösen, ihn stärker als 
zuvor in kollaborative und vernetzte Arbeitsprozesse einzubinden sowie sein 
spezifisches Expertenwissen systematisch für die Gesamtorganisation nutzbar 
zu machen. Damit wird selbst den Hochqualifizierten nunmehr die Souverä- 
nität über die individuelle Arbeits- und Zeitplanung mitsamt der Hoheit über 
ihren persönlichen Arbeitsrhythmus ein Stück weit streitig gemacht. 


Verlust von Freiräumen und Kontrolle 

Wie grundlegend und einschneidend dieser Umbruch für die hochqualifizierten 
Experten ist, wird in unseren Fallstudien an ihren Vorbehalten gegen Lean und 
die agilen Methoden deutlich. Diese äußern sich bereits bei der Konfrontation 
mit eher niedrigschwelligen Lean-Methoden im Rahmen der Büroorganisation, 
wie z.B. dem Aufräumen des individuellen Arbeitsplatzes nach der 5S-Methode. 
Akademiker, die es bereits aus dem Studium gewohnt sind, in einem hohen Maß 
eigenständig zu arbeiten, erleben solche Maßnahmen mitunter als eine Form 
von »Bevormundung« und »Gleichschaltung«. Sie werden als Widerspruch zur 
ehemals vorherrschenden Expertenkultur verstanden, in der der Einzelne noch 
das Vertrauen des Managements genoss und entsprechend hohe Freiheitsgrade 
und Autonomiespielräume hatte. 

Während es in diesem Fall noch eine relativ einfache Standardisierungsmaß- 
nahme ist, die bereits als Bedrohung von Autonomie und Verletzung legitimer 
Freiheitsgrade wahrgenommen wird, wird der Widerspruch zum traditionellen 
Expertenmodus insbesondere in weiten Teilen der Software-Entwicklung noch 
viel eindeutiger erfahrbar. Im Zuge der Einführung eines neuen industrialisier- 
ten Entwicklungsmodells verändern sich hier auch die Kernarbeitsprozesse der 
Entwickler. Wenn mit agilen Methoden in Verbindung mit Lean ganze Entwick- 
lungsabteilungen in einem einheitlichen Takt »zum Schwingen gebracht« wer- 
den, dann bleibt das nicht ohne Konsequenzen für die Arbeit der einzelnen Ent- 
wickler. Unsere empirischen Ergebnisse zeigen, dass durch die Einbindung ihrer 
Tätigkeiten in einen objektiven - standardisierten und arbeitsteiligen - Prozess 
und in kollaborative Arbeitszusammenhänge ein Teil ihrer bisherigen Freiräu- 
me verloren geht. Weil alle zu erledigenden Aufgaben im digitalen Backlog ab- 
gebildet sein müssen, können die Entwickler nicht mehr selbst bzw. zumindest 
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nicht mehr allein entscheiden, was sie konkret entwickeln. »Wo bleibt da meine 
Kreativität«, fragen sich unsere Gesprächspartner daher oft in den Interviews. 

Wie bedeutend der Umbruch im Rahmen des neuen Entwicklungsmodells 
und wie einschneidend der Verlust der einstigen Freiräume für die Entwickler 
ist, wird insbesondere dann deutlich, wenn man die neue Situation mit dem 
Arbeitserleben im traditionellen Expertenmodus vergleicht. Die traditionelle 
Entwicklertätigkeit wird von den Befragten oft noch mit der eines »freischaf- 
fenden Künstlers« verglichen, dessen Arbeitssituation durch Kreativität, einen 
ganzheitlichen Charakter der Tätigkeit und durch Eigenverantwortung geprägt 
war - z.B. hatten die einzelnen Entwickler oft einen viel engeren und direkteren 
Kontakt zu den Kunden sowie größeren unmittelbaren Einfluss auf die Produkt- 
entwicklung. Die neue Erfahrung, Aufgaben nur noch »abarbeiten« zu dürfen, 
wird infolgedessen mit der Arbeit an einem Fließband verglichen: »Man kommt 
sich so ein bisschen vor wie jemand, der am Fließband steht und nur kleine Teile 
entwickelt.« 

Analoges gilt in Bezug auf die Hoheit über den persönlichen Arbeitsrhyth- 
mus, der den Expertenmodus auszeichnet. Unsere Ergebnisse zeigen, dass die 
synchrone, kurzzyklische Taktung im neuen Entwicklungsmodell und das Prin- 
zip der kontinuierlich zu liefernden Usable Software den persönlichen Arbeits- 
rhythmus der Beschäftigten verändern. Insbesondere die vielen zeitlichen Puf- 
fer, die den alten Modus auszeichneten, gehen verloren, nicht zuletzt weil in den 
Entwicklungsorganisationen durch das Lean-Konzept mit der Synchronisation 
der Entwicklungsarbeit und dem abteilungsübergreifenden, einheitlichen Takt 
die Interdependenzen zwischen den einzelnen Teams zugenommen haben. 
Dadurch verlieren die Entwickler einen Teil ihrer souveränen Kontrolle über 
ihre eigene Zeit- und Arbeitsplanung und die Möglichkeit, ihrem persönlichen 
Rhythmus folgend in individuellem Tempo zu entwickeln. Damit wird die 
Arbeit subjektiv oft als »stressiger« empfunden, »weil ich eben nicht mehr mein 
eigener Herr bin«, so ein Software-Entwickler. 


Öffnung und Verteidigung des Expertenmodus 

Während die Veränderung der Kernarbeitsprozesse im Zuge des neuen industria- 
lisierten Entwicklungsmodells vor allem die Software-Entwickler betrifft (aber - 
wie unsere Fallstudie F zeigt - allmählich auch in der klassischen, Hardware- 
orientierten Ingenieursarbeit Verbreitung findet), spielt die Herauslösung des 
Einzelnen aus seinem individuellen »Expertensilo« in nahezu allen Bereichen der 
hochqualifizierten Angestelltentätigkeit eine zentrale Rolle. Und sie führt nicht 
zuletzt zu entsprechenden Widerständen seitens der Betroffenen, wie unsere em- 
pirischen Fallbeispiele eindringlich zeigen. Schon niedrigschwellige Methoden 
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des kommunikativen Austauschs im Rahmen von »Stehungen« oder Daily Scrums 
werden von den Beschäftigten oft als »Überwachung« und »Kontrolle« erlebt, 
die sich mit einem gewissen »Rechtfertigungsdruck« im Team, aber auch gegen- 
über dem Management verbinden. Eine Führungskraft in Fallunternehmen A 
beschreibt dies als eine gewollte Einschränkung der »Privatsphäre«: Durch die 
neue Transparenz und Kollektivität im Team soll die Qualität der Arbeitsplanung 
verbessert werden. Für »gestandene Entwickler«, die für sich aufgrund ihrer jah- 
relangen Erfahrung in Anspruch nehmen, zu wissen, was sie zu tun haben, er- 
scheinen der verpflichtende, regelmäßige »Rapport« und die Nötigung zur Offen- 
legung ihrer Vorgehensweise bei der Arbeit als eine Art »Gängelung«. 

Die sich in solchen Wahrnehmungen manifestierende Infragestellung der 
Anerkennung als Experte und der Eindruck von Vertrauensverlust und Bevor- 
mundung, der damit verbunden ist, führen in den von uns untersuchten Fällen 
bei vielen Entwicklern zu einem Gefühl persönlicher Verletztheit, das zur Grund- 
lage individuell widerständiger Handlungen gegen die neuen Methoden werden 
kann. Ein Entwickler aus Fallunternehmen C berichtet etwa, er sei inzwischen 
zu einer Art »Boykott« gegen die Offenlegung seines Arbeitsstandes übergegan- 
gen, indem er regelmäßig angibt, »nichts Neues zu berichten« zu haben. 

Solche Formen des individuellen Widerstands gegen die Öffnung des »Ex- 
pertensilos« finden sich in den hochqualifizierten Bereichen viel häufiger als 
z.B. in den Verwaltungsbereichen, wo die individuelle Expertenkultur weniger 
ausgeprägt ist und auch geringere Primärmachtpotenziale bestehen. Der Wider- 
stand der Experten äußert sich in unseren Fallstudien oft in vielen kleinen, eher 
subversiven Aktionen, die darauf zielen, die neuen Methoden mittels Überspit- 
zung ad absurdum zu führen. Er äußert sich aber auch in Formen individuel- 
ler Blockadehaltung, z.B. darin, dass die täglichen Besprechungen am Board 
entweder »geschwänzt« oder nur dem Schein nach umgesetzt werden, sodass 
diese Meetings im Vergleich zu den Verwaltungsbereichen weniger kontinu- 
ierlich und nur selten täglich durchgeführt werden. Oder er äußert sich darin, 
dass etwa das Burndown-Chart im IT-System, das den Arbeitsfortschritt doku- 
mentiert, nicht kontinuierlich gepflegt wird, sodass nicht transparent wird, wie 
schnell oder wie langsam die Beschäftigten bei der Abarbeitung vorankommen. 
In der Praxis entstehen dann regelrecht Formen eines »potemkinschen Scrum« 
bzw. »potemkinschen Lean« - besonders anschaulich etwa in unseren Fallstu- 
dien C, D und F -, in denen zwar die Institutionen scheinbar »nach Lehrbuch« 
umgesetzt werden, aber mangels aktiver Beteiligung der Beschäftigten nie wirk- 
lich »mit Leben gefüllt« werden. 

Die Widerstände gegen die neuen Formen der Arbeitsorganisation im Rah- 
men von Lean und agilen Methoden sind Ausdruck des Versuchs, am individu- 
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ellen Expertenmodus festzuhalten und ihn zu verteidigen. Sie richten sich gegen 
die Verletzung von Anerkennungsordnungen und Vertrauensbeziehungen, die 
für die privilegierte betriebliche Stellung der Experten - mit großer Autonomie, 
speziellen Freiheitsgraden in der Arbeit und hoher Wertschätzung - bislang cha- 
rakteristisch waren. Der in unserer Empirie zum Ausdruck kommende Bruch 
mit diesen »impliziten Verträgen« (Kotthoff 1997; Rousseau 1995; Raeder/Grote 
2001) wird von den Betroffenen als eben jene »Zeitenwende« und als Übergang in 
eine neue Arbeitswelt erlebt, in der - wie es ein Befragter aus Fallunternehmen A 
ausdrückt - selbst Hochqualifizierte »mehr oder weniger austauschbar« werden. 


Kollaboration und Kollektivierung des Expertenwissens 

Die Erhöhung der Austauschbarkeit ist eine zentrale Folge für die Beschäftigten, 
die aus der Öffnung der »Expertensilos« resultieren kann. Die Digitalisierung 
stellt die Unternehmen vor die Herausforderung, »agiler« zu werden und Inno- 
vations- und Entwicklungsprozesse flexibler und schneller zu gestalten. Viele 
Unternehmen reagieren darauf, indem sie die Potenziale einer neuen Qualität 
geistiger Produktivkraft adressieren. Sie versuchen die Abhängigkeit von indi- 
viduell gebundenem Expertenwissen zu reduzieren und es zu »kollektivieren« 
bzw. in transparentes und jederzeit zugängliches Organisationswissen zu über- 
führen. Das Aufbrechen der individuellen »Wissenssilos« erfolgt dabei - wie 
unsere empirischen Ergebnisse veranschaulichen - vor allem durch die Einbin- 
dung der einstigen »Individual-Experten« in transparente, kollektive und kol- 
laborative Arbeitsformen. In unseren Fallstudien spielen dabei sowohl digitale 
Entwicklungs- und Kollaborationsumgebungen eine Rolle als auch den Arbeits- 
prozess begleitende Plattformen zum Wissensaustausch, wie etwa interne »Wi- 
kis«, auf denen Entwickler alle relevanten Informationen speichern, wechsel- 
seitig kommentieren und ergänzen. Von nicht zu unterschätzender Bedeutung 
ist aber vor allem der unmittelbare kommunikative Wissensaustausch, der bei 
den regelmäßigen Daily Scrums und »Stand-ups« stattfindet. Das Gleiche gilt 
für neue Formen der Zusammenarbeit, wie z.B. das Pair Programming, bei dem 
zwei Entwickler gemeinsam programmieren statt jeder nur für sich im »stil- 
len Kämmerlein«. Die Relevanz neuer Kollaborationsformen und verschiedener 
Institutionen zur Kollektivierung personal gebundenen Expertenwissens wird 
insbesondere am Beispiel der jüngeren Beschäftigten deutlich. Sie profitieren 
naturgemäß in besonderem Maße davon, wenn die »Wissenssilos« ihrer erfahre- 
nen Kollegen geöffnet werden: Sowohl durch die Einblicke in deren Arbeit als 
auch durch die Rückmeldung und das Feedback zu ihrer eigenen Arbeit können 
sie die Expertise ihrer Kollegen für sich nutzen. Darüber hinaus lernen sie von 
den Erfahrungen der Älteren, wenn es darum geht, sich in neue Themenfelder 
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einzuarbeiten, oder wenn sie neue Aufgaben planen und strukturieren sowie 
Aufwände realistisch schätzen müssen. 

Was aus der Perspektive der Jüngeren als Erleichterung in und Unterstüt- 
zung bei der Arbeit sowie als Möglichkeit für kollektives Lernen im Team er- 
scheint, kann jedoch von älteren Beschäftigten als regelrechter Angriff auf ihr 
ausgeprägtes Spezialistentum und somit auf ihr Selbstverständnis gewertet wer- 
den. Unsere Empirie zeigt, dass sie die Aufforderung, über lange Jahre aufgebau- 
te Fachkenntnisse nun systematisch zu teilen, nicht selten als Entwertung und 
Mangel an Wertschätzung begreifen. Darüber hinaus kann die so betriebene 
Kollektivierung individuellen Wissens auch Ängste und Unsicherheitsgefühle 
wecken. Das gilt naturgemäß insbesondere für Unternehmen und Bereiche, die 
von Kostensenkung und Personalabbau geprägt sind. In unseren Fallstudien 
wird deutlich, worauf es bei der Herauslösung des Einzelnen aus seinem indi- 
viduellen »Expertensilo« ankommt: Ohne Vertrauen und Sicherheit können die 
Potenziale einer neuen Qualität der Nutzung geistiger Produktivkraft, wie sie 
etwa aus neuen Formen der Zusammenarbeit und einer kollektiven Wissensba- 
sis in der Organisation resultieren, nicht vollständig genutzt werden. Im Gegen- 
teil werden so Vorbehalte, Ängste und daraus resultierende Widerstände seitens 
der Beschäftigten überhaupt erst erzeugt. 

Ein anderer Auslöser für die genannten Blockadehaltungen der Beschäftigten 
ist oft, dass sie die Zunahme von Transparenz und den regelmäßigen fachlichen 
Austausch am Board nicht als Erleichterung in der Arbeit und Unterstützung 
entschlüsseln können, weil die Kompetenzprofile in den Teams zu unterschied- 
lich sind und sich zu wenig überlappen. Dies schränkt die Möglichkeiten zum 
effektiven Wissensaustausch, aber auch zur Kooperation und zur gegenseitigen 
Entlastung und Unterstützung ein, wie es z.B. die Beschäftigten in unseren Fall- 
studien E und F thematisieren. Die Entwickler müssen hier ihre Arbeitsplanung 
gemeinsam im Team kalibrieren und sich einem Rechtfertigungsdruck ausset- 
zen. Im Gegenzug werden ihnen aber die potenziellen Vorteile des regelmäßi- 
gen kollektiven Austauschs und der gemeinsamen Planung kaum erfahrbar. 

Mit Blick auf die Nutzung einer neuen Qualität geistiger Produktivkraft zur 
Erhöhung der Geschwindigkeit und Flexibilität in den Innovations- und Ent- 
wicklungsprozessen gilt zuammengenommen: Der Sinn von Transparenz und 
die Vorteile einer kollaborativen Arbeitsweise und kollektiven Wissensbasis 
müssen für die Beschäftigten erfahrbar werden. Nur so können sie dazu bewegt 
werden, ihre Ungewissheitszonen freiwillig preiszugeben und auf strategische 
Primärmachtpotenziale zu verzichten. Ohne entsprechende Kompensationen, 
wie Vertrauen, Sicherheit oder Unterstützung im Team, kann den hochquali- 
fizierten Experten nicht einsichtig werden, warum sie ihre »Expertensilos« auf- 
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geben sollten. Das Festhalten am individuellen Expertenmodus erscheint dann, 
wie unsere Fallstudien zeigen, als eine legitime Strategie für den Selbstschutz 
und für die Verteidigung bisheriger Privilegien. 


Zwei Varianten der Aufhebung des Expertenmodus 

Anhand der vielfältigen Strategien, mit denen die Unternehmen versuchen, die 
einzelnen Experten aus ihren »Silos« herauszulösen, wird deutlich, dass die di- 
gitale Transformation sehr wohl auch in den kreativen Arbeitsfeldern angekom- 
men ist. Im Gegensatz zu dem, was in der öffentlichen Debatte suggeriert wird, 
zeigen unsere empirischen Ergebnisse, dass die ehemals »geschützten Inseln« der 
Experten unter Druck geraten sind. Im Sog einer von disruptiven Umbrüchen 
erschütterten Ökonomie ermöglichen es neue Formen der Industrialisierung, 
den bürokratischen Expertenmodus zu unterminieren. In unseren Fallstudien 
dominiert dabei eine von den Beschäftigten als negativ erlebte Variante der Auf 
hebung des Expertenmodus, in der hochqualifizierte Kopfarbeit »wie an einem 
Fließband« organisiert ist und neuen Formen der Kontrolle unterliegt. Für die 
befragten Beschäftigten verbindet sich diese Variante mit Gefühlen von Aus- 
tauschbarkeit, Unsicherheit und Bevormundung sowie mit Anerkennungsver- 
lusten, Rechtfertigungsdruck und mit neuen Belastungen, die in der Arbeit zu 
widerständigen Haltungen und Handlungen führen können. 

Anhand unserer Empirie können wir aber auch zeigen, wie eine positive 
Aufhebung des Expertenmodus aussieht, bei der es - wie in den Fallstudien C, 
E und F - gelingt, die Experten »mitzunehmen«. Entscheidend ist hier, dass den 
Beschäftigten mit dem Konzept des Empowerments ein kompensatorisches An- 
gebot gemacht wird, das ihnen Vertrauen und Sicherheit gibt und die Vorteile 
z.B. von Transparenz im Rahmen neuer kollaborativer Arbeitsformen und einer 
kollektiven Wissensbasis persönlich erfahrbar macht. Unter diesen Umstän- 
den - wenn die Aufhebung des Expertenmodus auch als eine Verbesserung der 
Arbeitsprozesse im Sinne der Beschäftigten erfahrbar wird -, so zeigen unsere 
Ergebnisse, sind die Experten durchaus bereit, individuelle Ungewissheitszonen 
und Primärmachtpotenziale zugunsten einer neuen Qualität der Nutzung geis- 
tiger Produktivkraft in einem Kollektivteam aufzugeben. 

In dieser Variante des Abschieds vom Expertenmodus entpuppt sich die Ver- 
wirklichung von Empowerment als der innere Kern einer neuen Arbeitskultur, 
die mit der Aufhebung des individuellen Experten in einem »echten« Kollektiv- 
team eine positive Alternative zum bisher vorherrschenden bürokratischen Ex- 
pertenmodus offeriert. Vom Entwicklerteam wird nicht mehr lediglich erwartet, 
sich an Prozessvorgaben zu halten, sondern sich aktiv einzubringen und selbst- 
ständig eigene Entscheidungen zu treffen. Dies betrifft die Arbeitsplanung, aber 
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auch die kontinuierliche Verbesserung der bestehenden Prozesse. Der Unter- 
schied dieser neuen Qualität der Selbstorganisation des Teams gegenüber jenen 
Formen, die als Bevormundung und »Fließband«-Arbeit erscheinen, besteht vor 
allem in einer entsprechenden Vertrauenskultur. »Wir sind weg von einer Check- 
listenmentalität«, beschreibt dies z.B. ein Beschäftigter aus Falluntnehmen F, 
»also einem Prozess, der mich an die Hand nimmt wie eine Kindergärtnerin.« 
Im Gegensatz dazu erhalte das Team hier eine »aktive Rolle«. Empowerment be- 
deutet dann sowohl Entscheidungsfreiheit als auch Verantwortung. Hier ist das 
Team eine autonome Einheit, die über hohe Gestaltungsspielräume verfügt und 
ihre Arbeitsmenge selbst steuern kann - teilweise bis hin zu den Inhalten der 
Arbeit. Auf dieser Grundlage - im Rahmen eines empowerten Kollektivteams - 
hat dann auch der Entwickler wieder das Gefühl, »er kann selbst entscheiden« 
und seine Arbeit »selbst zu Ende bringen, ohne dass er ständig kontrolliert wird«. 
Nicht zuletzt gelingt es so auch, die Belastungssituation des Einzelnen im neuen 
industrialisierten Entwicklungsmodell zu steuern und zu entschärfen (vgl. dazu 
auch den folgenden Abschnitt). 

So sehr sich die beiden Varianten des Abschieds vom Expertenmodus auch 
unterscheiden, gemeinsam ist ihnen, dass sie das bisherige individualistische Ex- 
pertentum zu überwinden versuchen, die hochqualifizierten Experten aus ihren 
»Silos« herausholen und in kollaborative Arbeitsformen einbinden, die entweder 
von einem »Fließband« oder von einem empowerten Team dominiert werden. 
In beiden Fällen gehen die Ungewissheitszonen und die individuelle Hoheit und 
Souveränität in der Arbeitsplanung verloren. Und: Beide Varianten sind miteinem 
neuen Selbstverständnis der Experten verknüpft - allerdings mit völlig entgegen- 
gesetzten Implikationen. Während beispielsweise in Fallunternehmen E - vor 
dem Hintergrund der Aufhebung der Trennung von Planung und Ausführung in 
einem empowerten Team - von einem »mündigen Ingenieur« und »eigenverant- 
wortlichen Mitarbeitern« die Rede ist, formuliert ein Entwickler in Fallunterneh- 
men D das Gegenstück in einer Arbeitswelt ohne Empowerment sehr prägnant, 
indem er den heutigen Entwickler mit einem Arbeiter vergleicht: »Der ist ein ech- 
ter Arbeiter geworden. [...] also normaler Angestellter, der seine Arbeit macht.« 

Auch wenn das Bild des hochqualifizierten Entwicklers als »echter Arbeiter 
am Fließband« in unserer Empirie dominiert, zeigen die ebenfalls in den Fall- 
unternehmen identifizierbaren »mündigen Mitarbeiter in empowerten Teams«, 
dass der Abschied vom traditionellen Expertenmodus nicht zwangsläufig zu 
Vertrauens- und Anerkennungsverlusten und entsprechenden Widerständen sei- 
tens der Beschäftigten führen muss. Sie geben zumindest eine Ahnung davon, 
wie die Potenziale einer neuen Qualität geistiger Produktivkraft im Sinne der 
Beschäftigten gestaltet und damit nachhaltig realisiert werden können. 
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4.4 Neue Belastungsszenarien im Büro: 
Wie nachhaltig sind Lean und die agilen Methoden? 


Ein wichtiger Befund unserer empirischen Studien ist, dass sich der Umbruch 
in der Kopfarbeit auf der Grundlage neuer Organisationskonzepte mit teilweise 
sehr weitreichenden Belastungen für die Beschäftigten verbindet. Ähnlich wie 
es aus wissenschaftlichen Untersuchungen zu den »Ganzheitlichen Produktions- 
systemen« in den direkten Produktionsbereichen bereits seit langem bekannt ist 
(vgl. z.B. Gerst 2010, 2011), zeigt sich nun auch in den indirekten Bereichen, dass 
Nachhaltigkeit bei der Einführung neuer Lean-Konzepte kein Selbstläufer ist. 

Bemerkenswerterweise lassen sich neue Belastungspotenziale insbesondere 
auch bei den Software-Entwicklern und Ingenieuren feststellen, die auf der Ba- 
sis agiler Methoden der Projektorganisation arbeiten. Während in der Literatur 
oft ein Potenzial agiler Methoden für eine Reduzierung von Arbeitsbelastun- 
gen hervorgehoben wird (vgl. z.B. Pfeiffer/Sauer/Ritter 2014) - z.B. weil mit 
der Einführung kurzzyklischer Release-Zyklen die typischen Belastungsspitzen 
am Ende von langwierigen »Wasserfallprojekten« entfallen -, zeigen unsere 
empirischen Erhebungen, wie mit der Einführung des neuen industrialisierten 
Entwicklungsmodells die Belastungen für die Beschäftigten erheblich gestiegen 
sind und gesundheitsförderliche Potenziale nicht genutzt werden können. Ins- 
besondere mit Blick auf die strenge Taktung der Arbeit ist in unseren Interviews 
immer wieder von »Dauerstress« und von einem Gefühl »permanenten Zeit- 
drucks« die Rede. 

Vor diesem Hintergrund besteht in der Praxis dringender Handlungs- und 
Gestaltungsbedarf. Wie oben wiederholt angesprochen, stehen insbesondere 
die Software-Entwicklung und die Forschungs- und Entwicklungsabteilungen 
klassischer Industrieunternehmen an einem Scheideweg, was den Einsatz neuer 
Organisationskonzepte angeht: Auf der einen Seite deutet sich eine Entwick- 
lungsdynamik an, die in Richtung einer »Kopfarbeit am Fließband« tendiert, 
damit die Sinnperspektive in der Arbeit der hochqualifizierten Beschäftigten 
bedroht! und mit entsprechenden Belastungen einhergeht. Dem steht die Per- 
spektive einer neuen Qualität der Nutzung geistiger Produktivkraft mit einer 
Entwicklungsdynamik in Richtung Empowerment und Nachhaltigkeit gegen- 
über. Um besser zu verstehen, woher diese entgegengesetzten Entwicklungs- 
perspektiven mit ihren entsprechenden Belastungsszenarien rühren, lohnt es 


1 | Zur Bedeutung einer manifesten Sinnperspektive für eine nachhaltige Arbeitskon- 
stellation vgl. die Diskussion über salutogene Potenziale in Anlehnung an den »Kohä- 
renzsinn« (Antonovsky 1979), z.B. Kämpf et al. (2011); Kämpf (2015). 
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sich, einen differenzierten Blick auf unterschiedliche Entwicklungsstadien und 
-pfade von Teams im Spannungsfeld zwischen einer bürokratischen und einer 
»agilen« Kultur zu werfen. Zur besseren Veranschaulichung der Entwicklungs- 
pfade haben wir ein Modell entwickelt, das wir im Folgenden kurz erläutern 
möchten (vgl. Abb. 1). 


Abbildung 1: Entwicklungspfade agiler Teams 


Zwischen »potemkinschem« Lean und empowertem Team 
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Vom bürokratischen zum formalen Lean-Team 

Die Ausgangslage unterschiedlicher Entwicklungspfade, wie wir sie in unserer 
Empirie rekonstruieren können, bildet zunächst das klassische »Additiv-Team« 
als bloße Zusammenfassung individueller Experten zu einer formalen Organi- 
sationseinheit. Es steht sinnbildlich für die bürokratische Teamkultur in einem 
traditionellen fordistischen Unternehmen. Kennzeichnend sind hier die strikte 
Trennung von Planung und Ausführung, starre Standards und Prozesse sowie 
eine Arbeitsweise auf Grundlage des individualistischen Expertenmodus mit 
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jeweils spezialisierten, voneinander abgeschotteten »Wissenssilos« und einer bü- 
rokratischen Projektorganisation nach dem »Wasserfallmodell«. Mit der Einfüh- 
rung des neuen industrialisierten Entwicklungsmodells in Verbindung von Lean 
und agilen Methoden verändert sich hier die Organisation und Arbeitsweise des 
Teams zunächst lediglich formal. Das heißt, die neuen Methoden (wie Backlog, 
Sprints und Daily Scrums) und auch die neuen Rollen (Scrum Master und Product 
Owner) werden zwar eingeführt und angewendet. Aber der Zeitraum ist oftmals 
noch zu kurz, als dass sich schon eine merkliche Änderung der wirklich geleb- 
ten Arbeitskultur abzeichnen könnte. 

Insbesondere in Fallunternehmen F konnten wir dieses Entwicklungsstadium 
eines »formalen Lean-Teams« ausführlich studieren. Die entsprechenden Teams 
zeichnen sich dadurch aus, dass sie im Hintergrund immer noch in der sequen- 
ziellen Logik bürokratischer Meilensteinplanung denken und die Arbeitspla- 
nung daran orientieren. Auch schneiden sie die einzelnen Arbeitspakete häu- 
fig noch so, dass sie nur von bestimmten Teammitgliedern bearbeitet werden 
können, die sich in speziellen Themenfeldern über Jahre hinweg Expertise auf- 
gebaut haben. Die individuellen »Expertensilos« werden also noch aufrecht- 
erhalten. 

Solche »Kinderkrankheiten« sind nicht ungewöhnlich und sogar nahelie- 
gend, bedenkt man die oft langjährige Historie, während derer die bürokrati- 
schen Prozessmodelle und der Expertenmodus die Arbeitskultur der Teams und 
Führungskräfte geprägt haben. Sie sind gewissermaßen das »Gepäck«, das die 
Akteure schultern und auf ihrem Weg in eine neue, agile Arbeitskultur erst ab- 
streifen müssen. Entscheidend ist jetzt, ob die einzelnen Entwickler dazu über- 
gehen, die neuen Methoden - durch individuell widerständige Handlungen und 
Blockaden - zu unterlaufen, und am traditionellen Expertenmodus festhalten 
oder ob sie als Team anfangen, die neuen Methoden »mit Leben zu füllen« und 
sich auf die neue agile Kultur einzulassen. 

Auf Grundlage unserer Empirie können wir einige Erfolgsfaktoren identifi- 
zieren, die letzteres zumindest wahrscheinlicher machen. Hier geht es zum einen 
um die Beteiligung der Mitarbeiter im Rahmen des Einführungsprozesses von 
Lean bzw. der agilen Methoden (sehr anschaulich ist, neben Fallstudie F, auch 
Fallstudie E). Entscheidend ist die Frage, ob ihnen die notwendigen Freiräume 
zugestanden werden, die neuen Methoden auszuprobieren und dann auch ge- 
mäß ihren Vorstellungen anzupassen, oder nicht. Zum anderen erweisen sich 
die Faktoren Vertrauen und Sicherheit als zentral. Wenn die Teams auf Selbst- 
organisation bauen können und wenn dementsprechend die Führungskräfte 
darauf verzichten, permanent von außen hineinzuregieren, trägt dies zu einer 
aktiven Lernhaltung und entsprechenden Entwicklungsschleifen des Teams bei. 
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Gleichzeitig zeigt sich - besonders anschaulich z.B. in Fallstudie D -, dass eine 
unsichere Zukunftsperspektive (etwa im Rahmen von Personalabbaumaßnah- 
men oder Verlagerungen ins Ausland) es den Beschäftigten deutlich schwerer 
macht, sich vorbehaltlos und mit voller Überzeugung auf die neuen Arbeits- 
methoden einzulassen. 


Das »empowerte Kollektivteam« in einer agilen Arbeitskultur 

Unsere Forschungsergebnisse zeigen, dass eine solche Orientierung entschei- 
dend dazu beitragen kann, das neue Entwicklungsmodell nach einer gewissen 
Zeit »ins Fliegen« zu bringen und dass die Teams den Übergang zu einer neu- 
en, agilen Arbeitskultur vollziehen. Diesen Entwicklungspfad bezeichnen wir 
als den eines »empowerten Kollektivteams«. Wir konnten ihn vor allem in den 
Fallunternehmen C und F untersuchen. Solche Teams, denen die Überwindung 
der »Kinderkrankheiten« gelungen ist, sind oft über Jahre hinweg zusammen- 
gewachsen und verfügen über eine entsprechende Stabilität und Konstanz in 
der Zusammensetzung. Die Experten arbeiten hier nicht mehr individuell in 
ihrem »Silo«, sondern permanent zusammen, sodass sich die Wissensdomänen 
der Teammitglieder zunehmend überlappen. Das heißt, der Sinn von Kollabora- 
tion, Transparenz und einer kollektiven Wissensbasis wird hier erfahrbar, weil 
die agile Kultur auch wirklich konsequent »gelebt« wird. Dabei hat insbesondere 
der kommunikative Austausch, z.B. im Rahmen der Daily Scrums, eine große 
Bedeutung. Er trägt entscheidend dazu bei, wie es ein Befragter aus Fallunter- 
nehmen F beschreibt, dass die Teammitglieder sich nicht mehr isoliert vonei- 
nander »irgendetwas vornehmen und so still vor sich hin hacken«. 

In unserer Empirie fällt dabei auf, dass das zentrale Charakteristikum dieser 
Vorreiter-Teams ihr Empowerment als eine wirklich autonom agierende Orga- 
nisationseinheit ist. Das heißt, sie verfügen in der täglichen Arbeit - als Team - 
über hohe Gestaltungsspielräume, können ihre Arbeitslast (den »Workload«) 
selbst definieren, übernehmen die Verantwortung und verfügen auch über die 
entsprechenden Bedingungen, dieser gerecht werden zu können. Das geht - zu- 
mindest in Einzelfällen - so weit, dass die Teams sogar einen erheblichen Ein- 
fluss auf den Inhalt ihrer Arbeit nehmen können. Infolgedessen erleben sich die 
Teams nicht mehr als nur von außen getrieben oder wie von einem Fließband 
getaktet. Stattdessen wird die Erreichung der von ihnen »committeten« Ziele 
subjektiv als sinnvoll erachtet und von den Entwicklern eigenverantwortlich 
vorangetrieben. 

Zentrale Voraussetzung für das Empowerment ist, dass die neuen Methoden 
und Institutionen als ein Hebel genutzt werden, eine neue soziale Praxis im 
Team zu etablieren. Durch die Lebendigkeit einer entsprechenden Kollabora- 
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tionskultur - angefangen von der gemeinsamen Planung und Zerlegung der 
Arbeit bis hin zur Transparenz im Team - gelingt es den Teams schließlich, als 
Kollektiv eine neue Qualität von Strategie- und Handlungsfähigkeit zu erlan- 
gen - und zwar jenseits des individualistischen Expertenmodus. Dies fängt be- 
reits bei der Arbeitsplanung an. Hier erweist sich insbesondere die gemeinsame 
Aufwandsschätzung für den Arbeitsplan (Backlog) als ein wichtiger Hebel. Zen- 
tral ist, dass nicht einfach nur ein Mittelwert und damit ein »Kompromiss« zwi- 
schen den individuell abweichenden Schätzungen gebildet wird, sondern dass 
Differenzen vor dem Hintergrund unterschiedlicher Erfahrungen und Sichtwei- 
sen ausdiskutiert werden und in einen Konsens münden. Mit der gemeinsamen 
Aufwandsschätzung entsteht so ein neues Instrument für das Team, um in den 
Projekten ein nachhaltiges Arbeitstempo zu realisieren. 

Komplementäre Bedingung für ein Gelingen ist das entsprechende Vertrau- 
en der Führungskräfte, ausgedrückt vor allem dadurch, dass insbesondere die 
Product Owner die Selbstorganisation des Teams, dessen Planung und Schätzung 
ernst nehmen und respektieren. In der Praxis heißt das z.B., dass der Backlog 
prinzipiell unangetastet bleibt, um Störungen von außen und Eingriffe in den 
Arbeitsplan des Teams zu vermeiden. In unserer Empirie zeigt sich, dass dies ein 
Prüfstein dafür ist, wie ernst das Empowerment der Teams wirklich genommen 
wird. Sollte es doch zu einer neuen Situation kommen, die eine Änderung des ur- 
sprünglichen Backlogs erforderlich macht - z.B. weil eine neue Kundenanforde- 
rung auftritt oder sich die Entwickler verschätzt haben -, dann ist entscheidend, 
dass das Team und der Product Owner gemeinsam nach einer Lösung suchen. 
Empowerment ist hier also kein einmaliger Akt, sondern das bestimmende Mo- 
ment in der Beziehung zwischen dem Team und den Führungskräften bzw. den 
Product Ownern, das produktive Aushandlungsprozesse erst ermöglicht. 

Das empowerte Team kann so zu einem »lernenden Team« werden, das 
permanent lernt, seine Aufwandsschätzungen zu verbessern, mit Störungen 
von außen ädaquat umzugehen und die Kollaboration im Team inklusive der 
Kollektivierung des Wissens aktiv voranzutreiben. Insbesondere die Institu- 
tion der Retrospektive im Rahmen der agilen Methoden kann dazu im Sinne 
einer kontinuierlichen Verbesserung genutzt werden. So kann das Team als 
Ressource zur gegenseitigen Unterstützung erfahrbar werden. Somit eröffnen 
sich neue Potenziale, die nicht nur Belastungen reduzieren, sondern auch salu- 
togene Ressourcen mit Blick auf die Sinnstrukturen in der Arbeit erschließen 
können. 

Mit Blick auf die Nachhaltigkeit des empowerten Kollektivteams sind ins- 
besondere die Eindrücke aus Fallunternehmen C interessant. Sie unterstreichen 
die Gefahr einer »eindimensionalen« Produktivitätssteigerung, die mittelfristig 
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zu einer Zunahme von Belastungen auch für empowerte Beschäftigte führen 
kann. Die Ergebnisse unserer Untersuchung zeigen hier, dass eine ausgeprägte 
Sinnorientierung und intrinsische Motivation zu einer kontinuierlichen Stei- 
gerung der Leistungsverausgabung führen kann - bis hin zu Situationen, in 
denen sich die Teams »selbst die Luft abdrehen« und »nicht mehr zum Luftholen 
kommen«, wie es in unseren Interviews anklingt. Um dies zu verhindern, ist es 
wichtig, dass empowerten Teams bewusst zugestanden wird, die Produktivität 
des neuen Entwicklungsmodells nicht bloß mit Blick auf die weitere Eliminie- 
rung von waste und die Erhöhung der Qualität und Geschwindigkeit zu nutzen. 
Um das Empowerment im Sinne einer wirklichen Nachhaltigkeit in der Arbeit 
nutzen zu können, wird es darauf ankommen, die im Team gewonnene kollek- 
tive Handlungs- und Strategiefähigkeit auf das Ziel eines »sustainable pace« zu 
orientieren. Durch eine organisierte Entschleunigung können so nicht nur die 
Teamressourcen geschont, sondern auch Spielräume für eine Kultivierung von 
»Slack« (vgl. Stachle 1991) sowie für Innovation und Kreativität geschaffen wer- 
den, die schließlich zur Realisierung von neuen Sinnpotenzialen in der Arbeit 
beitragen. 


»Potemkinsche Lean-Teams« 

Teams, die es nicht schaffen, das neue Entwicklungsmodell nach einer gewis- 
sen Zeit »ins Fliegen zu bringen«, stagnieren auf der ersten Entwicklungsstufe 
einer bloß formalen Umsetzung der agilen Methoden. Die »Kinderkrankheiten« 
verfestigen sich dann, d.h. der Sinn der neuen Methoden wird systematisch 
unterminiert und der traditionelle Expertenmodus mit seiner bürokratischen 
Arbeitskultur verteidigt. Die neue, agile Arbeitskultur wird nicht nur nicht »mit 
Leben gefüllt«, sondern sowohl von den Entwicklern im Team als auch von den 
Führungskräften quasi in einem stillschweigenden Konsens abgelehnt. Diesen 
Entwicklungspfad bezeichnen wir als den eines »Potemkinschen Lean-Teams«. 
Wir konnten ihn ebenfalls in den Fallunternehmen C und F sowie außerdem 
im Fallunternehmen D eingehend untersuchen. 

Die agilen Methoden werden hier nur rudimentär bzw. pro forma umgesetzt 
oder - wie in Fallunternehmen D - gleich in ein Kanban-Modell überführt. In 
der Praxis äußert sich dies darin, dass vor allem die Arbeitsplanungen unterhalb 
der Oberfläche des formalen Scrum-Frameworks wieder »klassisch« gemacht 
werden: Die Aufgaben werden dann etwa vom Product Owner einzelnen Team- 
Mitgliedern unmittelbar zugewiesen. Dementsprechend wird auch die Auf- 
wandsschätzung nicht im Sinne eines kollektiven Lern- und Entscheidungspro- 
zesses gelebt und teilweise sogar komplett aufgegeben. Auch die Zerlegung der 
Aufgaben wird nicht mehr gemeinsam vom Team, sondern vom Product Owner 
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erledigt oder ebenfalls aufgegeben. Die neuen Methoden mit ihren Rollen und 
Institutionen können so nicht wirkmächtig werden. 

So werden auch die »Stand-ups« bzw. Daily Scrums in diesen Teams nicht 
mehr täglich, sondern nur noch ein- bis zweimal in der Woche durchgeführt 
und/oder von den Team-Mitgliedern regelmäßig »geschwänzt« bzw. unterlau- 
fen, indem entweder nichts berichtet wird oder nur so abstrakt, dass der Inhalt 
der Arbeit für andere kaum nachvollziehbar ist. Auch die Arbeitspraxis selbst 
ist weiter durch ein hohes Maß an Spezialistentum geprägt, nicht zuletzt weil 
bereits vor dem Planning-Meeting schon vorgezeichnet ist, wer welche Aufgabe 
übernimmt. Damit ist hier insbesondere der mit Lean und Scrum verbundene 
Paradigmenwechsel vom individuellen Expertenmodus mit seinem »Einzel- 
kämpfertum« hin zum »Kollektivteam«, das durch sein Empowerment zur zen- 
tralen Instanz kollektiver Handlungsfähigkeit wird, blockiert, da eingespielte 
Routinen der Arbeitsteilung, aber auch Zeitdruck einer gelebten Kollaborations- 
kultur und einer intensiven Wissensteilung im Team entgegenstehen. 

Als Ursachen für die Entwicklung zu einem »potemkinschen Lean-Team« 
lassen sich anhand unserer Fallstudien unterschiedliche Faktoren benennen. 
So fehlt vor allem in Bereichen, die wie in Fallunternehmen D durch Kosten- 
senkungs- und Personalabbaumaßnahmen geprägt sind, oftmals das Vertrauen, 
sich auf die neuen Methoden und vor allem die Transparenz vorbehaltlos ein- 
zulassen. Die Beschäftigten fürchten dann neue Möglichkeiten der Kontrolle 
und auch die wachsende Austauschbarkeit des einzelnen Entwicklers, sodass 
sowohl personale Vertrauensbeziehungen im Team und zu den Vorgesetzten als 
auch ein »Systemvertrauen« in das Unternehmen einer Grundlage entbehren. 
Insbesondere in den Fallunternehmen C und F lassen sich zwei weitere Fak- 
toren sehr eindringlich studieren. So fehlt es den Teams hier oft an Stabilität 
in ihrer Zusammensetzung. Weil sie immer wieder - teilweise sogar während 
eines Sprints - auseinandergerissen werden, können sie keine gemeinsame Kol- 
laborationskultur herausbilden und folglich auch keine kollektive Wissensbasis 
jenseits der individuellen »Expertensilos« aufbauen. Insbesondere Formen der 
Transparenz, aber auch der kollektiven Planung können so in ihrem Sinn nicht 
erfahrbar werden und das Team kann nicht als Ressource zur Entlastung und 
Unterstützung des Einzelnen entschlüsselt werden. 

Die wichtigste Ursache für Formen eines »potemkinschen Lean« liegt jedoch 
in einem »gebremsten« bzw. unterminierten Empowerment der Teams. Insbe- 
sondere in Bereichen beispielsweise des Fallunternehmens C, wo 60 Prozent der 
Arbeitsplanung vom Management zentral vorgegeben sind (die zudem die Ent- 
wickler real bereits voll auslasten), haben die Teams verständlicherweise nicht 
das Gefühl, ihre Arbeitslast wirklich selbst steuern zu können. Infolgedessen 
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verliert ein aktiver, eigenverantwortlicher Prozess des Commitments an Bedeu- 
tung, weil der gemeinsamen Aufwandsschätzung im Team der Boden entzogen 
wird. Das gilt gleichfalls, wenn etwa Führungskräfte das Empowerment der 
Teams unterminieren, indem sie während eines Sprints von außen in die ab- 
gestimmte Arbeitsplanung intervenieren, sodass die gemeinsame Planung und 
das Schätzen der Arbeitsaufwände im Team durch ungeplante Aufgaben »on 
top« konterkariert werden, oder z.B. indem sie Teammitglieder spontan abzie- 
hen. Die kollektive Arbeitsplanung im Team und die gemeinsame Aufwands- 
schätzung werden ohne Respektierung durch das Management zu inhaltsleeren 
Ritualen, die nicht als Ausgangspunkt für kollektive Lernprozesse im Team ge- 
nutzt werden können und dementsprechend bald unter dem Druck des Arbeits- 
alltags aufgegeben werden. 


»Verbrannte« Teams 

Solche Formen eines »potemkinschen Lean« auf der Basis agiler Methoden 
ohne echtes Empowerment erhöhen die Gefahr einer Entwicklungsdynamik 
in Richtung »verbrannter Teams«. Denn durch die Einbindung in das neue Ent- 
wicklungsmodell sind die Teams im Zuge von Lean einer starken Taktung mit 
einem kurzzyklischen Lieferdruck ausgesetzt. In Verbindung mit der systemi- 
schen Integration des Entwicklungsprozesses gehen so - ganz im Sinne der Lean 
Production - zeitliche und organisatorische Puffer verloren. Ohne ein wirkliches 
Empowerment verfügen die Teams aber nicht über kompensatorische Entla- 
stungs- und Schutzmechanismen, die ihnen die Möglichkeit geben könnten, ihre 
Arbeitslast selbst zu steuern. Die Folge ist dann häufig eine massive Zunahme 
der Belastungen in der Arbeit, die sich in dem Empfinden einer Arbeit »wie am 
Fließband«, einer systematischen und permanenten Überforderung und Sinn- 
verlust äußert. 

In unserer Empirie konnten wir viele dieser »verbrannten Teams« finden. Sie 
zeichnen sich durch einen permanenten »Ausnahmezustand« aus, in dem die 
Teams nur noch in einer Art »Firefight-Modus« agieren und die Arbeitslast aus 
verschiedenen Gründen nicht mehr bewältigt werden kann. Gesundheitliche 
Beeinträchtigungen, eine entsprechend schlechte Stimmung und Unzufrieden- 
heit bei den Beschäftigten sind die Folge. Vor dem Hintergrund fehlenden bzw. 
unzureichenden Empowerments stehen die Beschäftigten dem Takt quasi wehr- 
los gegenüber. Infolgedessen können die salutogenen Potenziale kaum mehr 
ihre Wirkung entfalten - z.B. hinsichtlich eines kollegialen Umgangs mit Be- 
lastungsspitzen. Die Teams erleben sich als von außen getrieben bzw. fremdbe- 
stimmt. In Fallunternehmen C etwa haben die Befragten das Gefühl, dass »von 
oben« Aufgaben und Funktionalitäten »eingekippt« werden, die dann unter ho- 
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hem Zeitdruck und immer wieder an der Grenze der Belastbarkeit »abgearbei- 
tet« werden müssen. Hier wird in den Interviews dann häufig auch wieder auf 
die Fließband-Metapher zurückgegriffen, womit ein Gefühl mangelnder Wert- 
schätzung und Anerkennung zum Ausdruck gebracht wird, aber eben auch die 
Erfahrung von fehlender Handlungsfähigkeit und zunehmendem Stress ange- 
sichts der engen Taktung in der Arbeit. 

In Fallunternehmen F lässt sich eine Belastungszunahme beispielsweise bei 
jenen Teams studieren, die einer hohen Maintenance-Last ausgesetzt sind, so- 
dass permanent ein Teil des Teams kurzfristig dazu abgestellt wird, Fehler bzw. 
ungeplante Kundenanforderungen zu bearbeiten, während der Rest des Teams 
dann mit reduziertem Personal die eigentliche Release-Planung bewältigen 
muss. Wenn sich abzeichnet, dass die Ziele des eigentlichen Release gefährdet 
sind, werden einzelne Experten vom Management aus anderen Teams abgezo- 
gen, die dann oftmals als Einzelkämpfer agieren und wiederum Lücken in ihre 
ursprünglichen Teams reißen. Teils weil die Arbeitsplanung der Teams oftmals 
keine »Puffer« für solche ungeplanten Aufgaben lässt, teils weil die Führungs- 
kräfte die Stabilität der Teams und ihre Hoheit über die Arbeitsplanung unter- 
minieren, indem sie von außen hineinregieren, entsteht so ein Teufelskreis: Es 
muss unter einem hohen Druck gearbeitet werden; unter diesen Bedingungen 
kommt es allerdings - z. B. infolge unzureichender Tests - zu neuen Fehlern und 
Folgeproblemen, die dann im nächsten Planungszeitraum wieder zutage treten 
und die Arbeitsplanung erneut konterkarieren. 

Das führt zu einem hohen Frustrationsgrad der Beschäftigten, nicht zuletzt 
weil sie den eigenen Ansprüchen an die Qualität ihrer Arbeit nicht mehr gerecht 
werden können. Im Zuge dessen und des hohen Drucks in der Arbeit kommt 
es so zu einer Belastungssituation, die bis hin zu gesundheitlichen Beeinträch- 
tigungen reicht. So ist bei den entsprechenden Teams häufig die Rede davon, 
»immer nur am Hetzen« zu sein. Die ungeplante Mehrarbeit und der Termin- 
druck führen dazu, »nicht mehr schlafen« zu können. Und insbesondere mit 
Blick darauf, wie der hohe Druck die Qualität der abgelieferten Arbeit unter- 
miniert, kommt es zu Sinnverlusten: »Also, man hat keine Chance, irgendwie 
es gut zu machen.« 


Von Empowerment zu Nachhaltigkeit 

Zusammenfassend lässt sich die Frage nach der Nachhaltigkeit von Lean und 
agilen Methoden in der Software-Entwicklung und Ingenieursarbeit wie folgt 
beantworten: Der Entwicklungspfad vom »potemkinschen Lean« zum »ver- 
brannten Team« veranschaulicht das Belastungspotenzial, welches mit dem 
neuen industrialisierten Entwicklungsmodell einhergeht. Mit Blick auf die Fol- 
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gen für die Beschäftigten erweist sich hier insbesondere das Empowerment als 
die entscheidende Herausforderung für eine nachhaltige Gestaltung von Lean. 
Ohne echtes Empowerment der Teams sind die Beschäftigten dem Belastungs- 
potenzial des neuen Entwicklungsmodells - insbesondere im Zuge der Taktung 
und des kurzzyklischen Lieferzwangs - wehrlos ausgeliefert, weil ihnen keiner- 
lei salutogene Ressourcen und Kompensationsstrategien im Team zur Verfü- 
gung stehen. 

Demgegenüber zeigt der Entwicklungspfad des »empowerten Kollektiv- 
teams«, dass die Verwirklichung von Empowerment vor allem die Fähigkeit der 
Teams betrifft, ihre Arbeitsmenge eigenverantwortlich zu steuern. Mit der ge- 
meinsamen Planung und selbstständigen Schätzung des Arbeitsaufwands ent- 
stehen grundsätzlich neue Instrumente, um ein nachhaltiges Arbeitstempo zu 
ermöglichen. Die Kollaboration im Team und die Entwicklung einer kollek- 
tiven Handlungs- und Strategiefähigkeit stellen eine entscheidende Ressource 
dar, salutogene Potenziale wie die Sinnperspektive oder die Handhabbarkeit in 
der Arbeit zu stärken und Belastungen zu reduzieren. 

Der Schritt zu einem empowerten Kollektivteam und die Entwicklung in 
Richtung wirklicher Nachhaltigkeit sind ein kontinuierlicher Prozess. Ohne ein 
Selbstverständnis des Teams als »permanent lernende Organisation« und ohne 
das Streben nach kontinuierlicher Verbesserung droht die Gefahr, wieder in alte 
Muster zurückzufallen und zu stagnieren - bis hin zu einer Abwärtsentwick- 
lung, die schließlich unter die Schwelle der bürokratischen Kultur zurückfällt 
und ebenfalls in ein »verbranntes Team« münden kann. Notwendig ist es da- 
her, die Lernprozesse im Team nicht lediglich eindimensional auf die Erhöhung 
der Geschwindigkeit und Verbesserung der Qualität zu richten, sondern vor 
allem darauf, die Potenziale der Produktivitätssteigerung für eine nachhaltige 
Geschwindigkeit und die Stärkung salutogener Potenziale, wie z.B. Spaß und 
Sinnorientierung in der Arbeit, zu nutzen. Ohne eine Orientierung auf einen 
schonenden Umgang mit den Ressourcen im Team und die Verbesserung der 
Arbeitsprozesse auch im Sinne der Beschäftigten werden die Potenziale der neu- 
en Qualität geistiger Produktivkraft nie voll ausgeschöpft werden können. 


204 


5 Ausblick 


Zwischen »digitalem Fließband« und Aufbruch 
in eine neue »Humanisierung der Arbeitswelt« 


Mit der digitalen Transformation und dem Einzug neuer Formen der Arbeits- 
organisation werden sehr grundlegende Veränderungen und Umbrüche in der 
Kopfarbeit angestoßen. Der Übertragung von Lean-Konzepten aus der Ferti- 
gung ins Büro und dem Einsatz agiler Methoden kommt dabei eine strategische 
Bedeutung zu: Komplementär zur informatorischen Durchdringung der Arbeit 
über digitale Informationssysteme liefern sie die adäquaten Konzepte, um die 
Arbeit der Angestellten neu zu organisieren. 

Hintergrund der Entwicklung ist die Herausbildung eines »neuen Typs der In- 
dustrialisierung« (Boes 2004), dessen Ausgangspunkt nicht mehr die klassischen 
Maschinensysteme der »großen Industrie« sind, sondern der »Informationsraum« 
(Baukrowitz/Boes 1996) ist. Lean-Konzepte und agile Methoden liefern hier An- 
satzpunkte, um die Wertschöpfungsprozesse im Büro entlang des digitalen In- 
formationsflusses zu organisieren. Davon ausgehend zielen die Unternehmen im 
Zuge gegenwärtiger Reorganisationen darauf, auch die Kopfarbeit systematisch 
und rational zu organisieren, um sie plan- und wiederholbar zu machen. Ähn- 
lich wie bei der Industrialisierung der Handarbeit im 19. Jahrhundert werden 
nun auch geistige Tätigkeiten im Sinne eines objektiven Prozesses strukturiert, 
um die Arbeitsprozesse im Büro unabhängig vom individuellen Geschick des 
Einzelnen organisieren zu können (vgl. Boes/Kämpf 2012; Boes et al. 2014a). 
Die konkreten Formen dieser Industrialisierung von Kopfarbeit - ihre Strate- 
gien, Konzepte und Reifegrade - differieren zwischen den unterschiedlichen 
Bereichen: Während sich in den mittelqualifizierten Verwaltungsbereichen eine 
Art »digitale Taylorisierung« Bahn bricht, die mit Lean-Methoden kombiniert 
wird, ist auf Basis der Verknüpfung agiler Methoden mit den Prinzipien der 
Lean Production in den höherqualifizierten Bereichen ein neues industrialisiertes 
Entwicklungsmodell entstanden, das sich in der Software-Entwicklung flächen- 


205 


Kapitel 5 


deckend durchsetzt und zunehmend auch in den industriellen Forschungs- und 
Entwicklungsabteilungen zum Einsatz kommt. 

Im Zuge der Versuche der Unternehmen, die Kopfarbeit einer neuen In- 
dustrialisierung zu unterziehen, kommt insbesondere der Öffnung der Ange- 
stelltenbereiche durch den Einzug von Transparenz eine zentrale Bedeutung 
zu. Neue Meeting-Routinen im Rahmen von Scrum oder der Übertragung des 
Shopfloor-Managements ins Büro zielen sowohl auf die Stärkung des kommuni- 
kativen Austauschs und der Selbstorganisation der Beschäftigten als auch auf die 
Verbesserung der Eingriffs- und Steuerungsmöglichkeiten für das Management. 
Für die Beschäftigten bedeuten sie aber auch eine Zunahme von Kontrolle bis 
hin zu einer Renaissance von »peer group pressure« (vgl. Vormbusch 1999) im 
Büro. Insbesondere hochqualifizierte Beschäftigte verlieren damit bisherige Un- 
gewissheitszonen und Primärmachtpotenziale. Somit zeigen unsere Untersu- 
chungen auch, dass die disruptive Wucht der digitalen Transformation vor den 
privilegierten akademischen Experten in der Software-Entwicklung oder den 
klassischen Ingenieursbereichen nicht halt macht. Sie werden zunehmend aus 
ihren »Silos« herausgelöst und in kollaborative Arbeitszusammenhänge sowie 
Formen der Kollektivierung ihres Expertenwissens eingebunden, die schließlich 
auf eine Aufhebung des »Expertenmodus« (Boes et al. 2014a; Boes/Kämpf/Lühr 
2016c) als der bisherigen Organisationsform insbesondere hochqualifizierter 
Kopfarbeit hinauslaufen. 

Mit Blick auf die Folgen für die Beschäftigten zeigt sich, dass der grundlegen- 
de Umbruch in der Organisation der Kopfarbeit durch Lean und agile Metho- 
den mit einem erheblichen Anstieg von Belastungen einhergehen kann. Diese 
reichen von steigendem Rechtfertigungsdruck, Unsicherheitserfahrungen und 
Anerkennungsverlusten im Zuge der Kontrolle durch Transparenz bis hin zu 
gesundheitlichen Beeinträchtigungen durch »Dauerstress« und »permanenten 
Zeitdruck« im Rahmen der kurzzyklischen Taktung des neuen industrialisier- 
ten Entwicklungsmodells etwa in der Software-Entwicklung. Dabei zeigt sich, 
dass die Nachhaltigkeit bei der Einführung neuer Lean-Konzepte - ähnlich wie 
schon in den unmittelbaren Produktionsbereichen (vgl. z. B. Gerst 2010, 2011) - 
kein Selbstläufer ist. Ohne ein wirkliches Empowerment der Teams können 
auch die gesundheitsförderlichen Potenziale z.B. der agilen Methoden nicht ge- 
nutzt werden. 


Am Scheideweg: Für oder gegen die Menschen? 

Der skizzierte Umbruch der Kopfarbeit in der digitalen Transformation verbin- 
det sich mit weitreichenden gesellschaftlichen Folgen, die von einer zunehmend 
»ausgebrannten Arbeitswelt« (Kämpf 2015) bis hin zu neuen Unsicherheiten für 
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die (lohnabhängigen) Mittelschichten im Zuge ihrer erodierenden betrieblichen 
Lage (vgl. Boes/Kämpf/Lühr 2016c) reichen. Vor diesem Hintergrund besteht in 
der Praxis dringender Handlungs- und Gestaltungsbedarf. Zugespitzt formu- 
liert zeigen unsere Ergebnisse, dass sich die Entwicklung gegenwärtig an einem 
Scheideweg befindet: Auf der einen Seite zeichnet sich das Bild einer Arbeits- 
welt ab, in der auch Kopfarbeit »wie am Fließband« organisiert und zunehmend 
austauschbar wird. Diese verbindet sich mit einer neuen Qualität von Kontrolle 
im Zuge der informatorischen Durchdringung der Arbeit und des Einzugs von 
Transparenz sowie mit einem massiven Anstieg der Belastungen im Büro. Auf 
der anderen Seite lassen sich aber durchaus die Potenziale für einen Aufbruch 
in eine neue »Humanisierung der Arbeitswelt« erkennen. Diese bestehen in 
der Ausweitung der Autonomie- und Handlungsspielräume für wirklich em- 
powerte Teams, in persönlichen Entwicklungs- und Entfaltungsmöglichkeiten 
im Zuge kollektiven Lernens und der Selbstorganisation des Teams sowie in 
den darin liegenden salutogenen Potenzialen für eine präventive Gesundheits- 
förderung. 

Die Grundlage für dieses positive Entwicklungsszenario besteht in der neuen 
Qualität der Nutzung geistiger Produktivkraft, die sich im Zuge des Produktiv- 
kraftsprungs auf der Basis des Informationsraums in Verbindung mit Lean und 
agilen Methoden abzeichnet. Sie bezieht sich vor allem auf die Etablierung kol- 
laborativer Arbeitsformen sowie die Kollektivierung personal gebundenen Ex- 
pertenwissens durch Informatisierung und kommunikativen Austausch. Unsere 
Empirie zeigt, dass die darin liegenden humanisierungspolitischen Potenziale 
in der Praxis immer wieder durchschimmern. So ist es gerade die Aufhebung 
des Expertenmodus, die es möglich macht, das Team als zentrale Ressource zur 
gegenseitigen Unterstützung und Entlastung etwa bei individuellen Belastungs- 
spitzen oder als Korrektiv und Erfahrungspool bei fachlichen Fragen und Ent- 
scheidungen zu nutzen. Auch zeigt sich, dass eine stärkere Zusammenarbeit im 
Team und die gemeinsame Planung der Aufgaben eine wesentliche Quelle z.B. 
von »Spaß« an und Zufriedenheit in der Arbeit ist, mithin die Sinnperspektive 
der Beschäftigten stärkt. Und es sind nicht zuletzt das Aufbrechen individueller 
»Wissenssilos« und die Schaffung einer transparenten, kollektiven Wissensbasis, 
die die Voraussetzungen nicht nur für teamzentrierte, kollaborative Arbeitsfor- 
men schaffen, sondern auch für kollektive Lernschleifen und individuelle Ent- 
wicklungsmöglichkeiten. 

Als entscheidender Dreh- und Angelpunkt mit Blick auf eine neue Humani- 
sierung von Arbeit erweist sich dabei das Empowerment der Teams. Je stärker 
es ausgeprägt ist, desto stärker empfinden die Beschäftigten das Vertrauen und 
auch die Sicherheit, die notwendig sind, um die Vorteile der neuen Transpa- 
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renz produktiv für sich zu nutzen. So wird eine neue Qualität von Selbstor- 
ganisation möglich, in der eine kollektive Strategie- und Handlungsfähigkeit 
zur Grundlage der Steuerung der eigenen Arbeitsmenge wird. Damit kann 
nicht nur das Tempo in der Arbeit eigenverantwortlich reguliert und damit das 
Belastungsniveau reduziert werden. Mindestens genauso wichtig ist, dass em- 
powerte Teams damit auch über jene Autonomie- und Entscheidungsfreiräume 
verfügen, die es möglich machen, die persönliche Entfaltung im Team und des 
Teams auf der einen Seite und die Steigerung der gemeinsamen Arbeitspro- 
duktivität auf der anderen Seite als »zwei Seiten einer Medaille« zu behandeln. 
Dies zeigt sich in dem Maße, in dem der Fokus der kollektiven Lern- und kon- 
tinuierlichen Verbesserungsprozesse nicht lediglich auf der Steigerung der Ge- 
schwindigkeit in der Arbeit und der Qualität des Produkts liegt, sondern auch 
aufeinem nachhaltigen, schonenden Umgang mit der eigenen Arbeitskraft und 
der Eröffnung völlig neuer Sinnpotenziale, etwa durch Etablierung von orga- 
nisatorischem »Slack« und die Schaffung von Freiräumen für Kreativität und 
Innovativität. 

Gerade das Empowerment der Teams und die Stärkung ihrer Handlungs- 
fähigkeit bilden deshalb aus unserer Perspektive die zentrale Leitorientierung 
für eine nachhaltige Gestaltung der Arbeitswelt. Hier bestehen humanisierungs- 
politische Potenziale, die allerdings in der Breite erst noch »zum Leben erweckt« 
werden müssen. So zeigt unsere Empirie, dass es in der Praxis der hochquali- 
fizierten Bereiche - sowohl in der Software-Entwicklung als auch in der indus- 
triellen Forschung & Entwicklung - durchaus Ansatzpunkte für ein »echtes« 
Team-Empowerment gibt, von denen man lernen kann. Allerdings prägen diese 
Beispiele das Bild nicht in der Breite, sondern sind eher die Ausnahme von der 
Regel. Ihnen kommt der Charakter eines »Leuchtturms« zu. 

In den mittelqualifizierten Angestelltenfeldern der Verwaltung hingegen 
ist - angesichts der alles dominierenden Suche nach zu beseitigender »Ver- 
schwendung« - von Empowerment meist nicht einmal die Rede. Allerdings 
zeigen einzelne Beispiele, dass auch hier neue Möglichkeiten für die Selbstor- 
ganisation der Teams entstehen. Vor dem Hintergrund weniger ausgeprägten 
Spezialistentums und größerer Redundanzen in der Arbeit bestehen teilwei- 
se sogar bessere Bedingungen, das Team als flexible Ressource zur Entlastung 
und Unterstützung des Einzelnen erfahrbar zu machen (z.B. bei individuellen 
Belastungsspitzen oder im Zuge der Kompensation krankheitsbedingter Aus- 
fälle). Und nicht zuletzt zeigt unsere Empirie auch, dass selbst die Rationali- 
sierungseffekte im Zuge kontinuierlicher Prozessoptimierung nicht ausschließ- 
lich als Bedrohung im Hinblick auf die Sicherheit des eigenen Arbeitsplatzes 
entschlüsselt werden müssen. Sie können dann anders interpretiert werden, 
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wenn die Efizienzgewinne genutzt werden, um die frei werdenden Kapazitä- 
ten für die Anreicherung der Tätigkeitsprofile zu verwenden. Hier bestehen 
also ebenfalls Möglichkeiten, Produktivitätssteigerungen mit der persönlichen 
Entfaltung der Mitarbeiter zu verbinden und die Beschäftigten - wie z.B. in 
Fallunternehmen B, wo die Belegschaft selbst Vorschläge für die Erweiterung 
ihrer Kompetenzen entwickelt - beteiligungsorientiert in die Umgestaltung 
ihrer eigenen Arbeit und die Weiterentwicklung ihrer Kompetenzprofile ein- 
zubinden. 

Insbesondere mit Blick auf die weitere Entwicklung der »Arbeitswelt der Zu- 
kunft«, in der Kopfarbeit bzw. wissensintensive Wertschöpfungsprozesse zuneh- 
mend an Bedeutung gewinnen, bietet die neue Qualität der Nutzung geistiger 
Produktivkraft die Chance für einen arbeitspolitischen Paradigmenwechsel, wie 
er bereits die Aktivitäten zur »Humanisierung des Arbeitslebens« (HdA) in den 
70er und 80er Jahren inspiriert hatte (vgl. Ochlke 2013). Dieser besteht in der 
Perspektive eines menschengerechten Produktivitätsfortschritts, der die Poten- 
ziale des Produktivkraftsprungs für die Menschen nutzt und nicht gegen sie 
wendet. Entsprechende Richtungsentscheidungen und eine gezielte gesellschaft- 
liche und politische Gestaltung des Umbruchs in der Kopfarbeit sind deshalb 
dringend notwendig. Naiver Technizismus kann dies kaum ersetzen, denn ohne 
die Menschen und deren aktive Beteiligung wird die sich abzeichnende Neuge- 
staltung der Arbeitswelt im Zuge der digitalen Transformation kaum erfolgreich 
sein. Gebraucht wird eine gesellschaftliche Leitorientierung, die die Menschen 
und ihre Rolle in der digitalen Transformation zentral stellt. Die Dynamik des 
Produktivkraftsprungs für einen Aufbruch in eine neue Humanisierung von 
Arbeit zu nutzen (vgl. Boes et al. 2016a) ist hier ein guter Ausgangspunkt. In 
diesem Sinne wird die Gestaltung des Umbruchs in der Kopfarbeit schließlich 
auch zu einem strategischen Thema für die betriebliche Interessenvertretung in 
den Angestelltenbereichen. 


Strategisches Thema für Betriebsräte 

Mit Blick auf die arbeitspolitische Gestaltung des Umbruchs in der Kopfarbeit 
gilt, dass die Umsetzung der neuen Methoden der Arbeitsorganisation im Büro 
nicht lediglich eine Frage der »technischen« Implementierung ist, sondern ein 
komplexer sozialer Veränderungsprozess. Unterschiedliche Faktoren spielen 
dabei eine Rolle und nehmen Einfluss auf die Bedingungen, unter denen die 
Leitorientierung einer neuen Humanisierung der Arbeitswelt konkret durchge- 
setzt werden muss. Diese reichen von der jeweiligen strategischen Ausgangssitu- 
ation der Unternehmen - also z.B. ihrer wirtschaftlichen Lage und Position am 
Markt - über die unterschiedlichen Machtpotenziale und Interessen verschie- 


209 


Kapitel 5 


dener Beschäftigtengruppen bis hin zu der »ideologischen« Einbettung, die die 
Umsetzung der neuen Organisationskonzepte rahmt.! 

Gerade weil die Implementierung von Lean-Konzepten in der Praxis häufig 
ein komplexer und mithin auch umkämpfter sozialer Veränderungsprozess ist, 
kommt es mit Blick auf die humanisierungspolitische Entwicklungsperspektive 
sehr auf eine autonome Arbeitsgestaltungspolitik der betrieblichen und gewerk- 
schaftlichen Interessenvertretung an. Bereits die HdA-Bewegung im letzten 
Jahrhundert hatte gezeigt, dass die Realisierung des Humanisierungspotenzials 
neuer Arbeits- und Produktionskonzepte kein Selbstläufer ist (vgl. z.B. Sauer 
2011). Heute zeigt sich dies nicht zuletzt darin, dass in der Praxis Lean und agi- 
le Methoden längst zu einem strategischen Thema für Betriebsräte geworden 
sind. Davon zeugen unter anderem entsprechende Initiativen für Betriebsver- 
einbarungen in den indirekten Bereichen. Ganz offensichtlich wächst hier der 
betriebliche Handlungs- und Regulierungsdruck (vgl. auch Bürkardt/Seibold 
2015). Dabei betrachten viele Betriebsräte die Gestaltung der neuen Organisa- 
tionskonzepte nicht zuletzt auch als eine Chance, ihre eigene Verankerung in 
den indirekten Bereichen auszubauen. Indem sie etwa bewusst als Vorreiter für 
eine beteiligungsorientierte Implementierung und Umsetzung auftreten, ge- 
lingt es ihnen, zu einem zentralen Akteur in der Auseinandersetzung um die 
Arbeitswelt der Zukunft zu werden. 

Dies lässt sich exemplarisch in Fallstudie B nachvollziehen. Hier zeigt sich 
zum einen, dass Betriebsräte gerade in industriellen Großbetrieben bei der Im- 
plementierung neuer Organisationskonzepte in den Büros der Angestellten auf 
ihre Erfahrungen bei der Einführung von Lean in der Produktion zurückgreifen 
können. So konnte der Betriebsrat eine innovative Gesamtbetriebsvereinbarung 
(GBV) für die indirekten Bereiche aushandeln, die auf den bestehenden Verein- 
barungen zu Lean in den direkten Produktionsbereichen aufbaut, und so unter 
anderem wichtige Mitbestimmungsrechte sowie Schutzbestimmungen hinsicht- 
lich der Arbeitsplatzsicherheit durchsetzen. Zum anderen veranschaulicht das 
Fallbeispiel auch, wie eine aktive Rolle des Betriebsrats bei der Implementierung 


1 | So sind z.B. die agilen Methoden bei vielen Software-Entwicklern selbst oft sehr 
positiv konnotiert, weil sie aus der Kritik am bürokratischen »Wasserfallmodell« ent- 
standen sind. Sie bieten damit aber auch die Möglichkeit, die »Künstlerkritik« (Boltans- 
ki/Chiapello 2003) der Beschäftigten zu inkorporieren und - wie anschaulich in Fall- 
studie C dargestellt - die Organisation der Software-Entwicklung in Verbindung mit 
dem Lean-Konzept zu einer Kopfarbeit »am Fließband« umzugestalten. Lean-Konzepte 
werden hingegen oft mit einem Fokus auf Kostensenkung und Vermeidung von »Ver- 
schwendung« eingeführt, was meist keine fruchtbare Ausgangslage für eine Beteiligung 
der Beschäftigten und eine Entwicklungsperspektive in Richtung Empowerment ist. 
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und Umsetzung von Lean im Büro ausschen kann. Hier zeigen die betrieblichen 
Interessenvertreter vor allem viel unmittelbare Präsenz, beteiligen sich an der 
Einführung von Lean-Projekten, um die Einhaltung der GBV zu überprüfen, 
nehmen unangekündigt an den Stehungen der Teams in den unterschiedlichen 
Bereichen teil und tauschen sich kontinuierlich mit den Beschäftigten selbst aus. 
Der Betriebsrat konnte in diesem Fall seinen Zugang zu den zuvor weniger be- 
triebsratsafinen Verwaltungsbereichen deutlich verbessern und die Vertrauens- 
beziehungen stärken.? 

Während Betriebsräte hier sehr gut an ihre Erfahrungen mit den »Ganz- 
heitlichen Produktionssystemen« anknüpfen können, erzeugen vor allem neue 
Konzepte, wie insbesondere Scrum als agile Methode der Projektorganisation, 
einen entsprechenden Qualifizierungsbedarf. Dies äußert sich nicht zuletzt auch 
in den entsprechenden Schulungsangeboten der Gewerkschaften. Insgesamt be- 
steht in Bezug auf die Gestaltung der neuen Organisationskonzepte im Büro 
ein konkreter Ansatzpunkt vor allem darin, Vertrauen und Sicherheit für die 
Beschäftigten zu schaffen. Sie bilden die notwendige Voraussetzung dafür, dass 
die neuen Methoden auch tatsächlich »ins Fliegen kommen« (woran nicht zu- 
letzt die Unternehmen selbst interessiert sind). Als wesentliche Spannungsfelder 
haben sich in der Praxis hingegen die Aspekte »Freiraum für Kreativität vs. Kopf- 
arbeit am Fließband« sowie »Nachhaltigkeit und gesundes Tempo vs. Taktung 
und permanenter Zeitdruck« erwiesen. Darüber hinaus bietet insbesondere das 
Thema Empowerment viel Potenzial für die interessenpolitische Begleitung 
des Umbruchs in der Kopfarbeit: Es eröffnet den Beschäftigten einen wichti- 
gen Raum, die Arbeitswelt der Zukunft im Zuge der digitalen Transformation 
selbstbewusst nach ihren Interessen und Bedürfnissen zu gestalten. Hier besteht 
somit auch der zentrale Ansatzpunkt für die Verankerung der gesellschaftspoli- 
tischen Leitorientierung der Humanisierung auf der betrieblichen Ebene. 


2 | Weitere interessante Erfahrungen und Beispiele in Bezug auf konkrete Handlungs- 
möglichkeiten von Betriebsräten finden sich finden sich z. B. bei Böhm (2015) und Bür- 
kardt/Seibold (2015). 
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